Embed magic bytes in .xopp files

[TheAssassin]

For reasons we all know, embedding magic bytes in a file, if possible, is a good idea. It makes the recognition of file types a lot more reliable than relying on extensions only.

In #1442 (comment) I showed where such bytes could be placed, and what they could look like. I simply embedded the string xopp at a static offset so it won't interfere with the existing gzip header and also doesn't touch the compressed payload.

This is a fork of the discussion in #1442 (comment) suggested by @LittleHuba.

[lciti]

I like the idea of magic bytes to identify the file type but I am unsure about the suggested implementation as it does not comply with the gzip header format (RFC1952). Those bytes are supposed to contain the modification time MTIME field. While xournalpp may not use it (yet?), having a confusing date (11 Oct 2029) does not sound like a good idea to me. I suggest we use one of the other fields. I think one way to do it would be using the FNAME or FCOMMENT fields. It should be as easy as using deflateSetHeader after opening the gzip file for writing.

If using FNAME:
$ hd aaa.pdf.xopp | head -1
00000000 1f 8b 08 08 00 00 00 00 00 03 78 6f 70 70 00 cd |..........xopp..|`

If using FCOMMENT:
$ hd aaa.pdf.xopp | head -1
00000000 1f 8b 08 10 00 00 00 00 00 03 78 6f 70 70 00 cd |..........xopp..|

[LittleHuba]

I'd skip this and add it to the new format. This is at most a papercut issue and there is no reason to modify the current format for this.

We should be able to add this in the made_by field of ZIP-files (right after the magic bytes of the zip file itself)