feat: new higher-performance rnote file format

[anesthetice]

The overall goal of this PR is to improve the handling of .rnote save files.

tl;dr

• Shorter loading times (~10x improvement*)
• Shorter saving times (~6x improvement*)
• Smaller file sizes (~12% reduction)

* This improvement factor only concerns going back and forth between the already loaded bytes of the file and their corresponding EngineSnapshot, on my system of course, your results may vary.

Main changes:

• Parallelized (de-)serialization and (de-)compression.
• Files saved with a compatible version are directly converted into an EngineSnapshot instead of always passing through a compatibility layer.
• Swapped the Deflate (gzip) compression algorithm for Zstandard (zstd).

Here's a diagram of the simplified process to get from EngineSnapshot to a .rnote save file and vice-versa.

Note that this PR is a re-write of #1177, some of the important changes being:

• (+) parallelism for serialization and compression
• (+) the introduction of a file version separate from the version of Rnote
• (-) scrapped save preferences (not worth complexity cost)
• (-) scrapped alternative serialization methods (for compatibility reasons)

[anesthetice]

@flxzt, @Doublonmousse, I'd say this PR is ready for review. Take all the time you need of course, and feel free to ask me for information, changes, etc. 🫡

[Doublonmousse]

Another thought on the atomic saving denomination.
I'm not sure we can really call the new version atomic saving per say.

That would be the case for a file format where any change we do inside the file is mapped back to the file through an efficient diff (and not a full write of the new engine state). For sqlite (#1173 (comment)), that would be the case because modifications to the file can be mapped back to the file through a push/commit

[anesthetice]

Another thought on the atomic saving denomination. I'm not sure we can really call the new version atomic saving per say.

That would be the case for a file format where any change we do inside the file is mapped back to the file through an efficient diff (and not a full write of the new engine state). For sqlite (#1173 (comment)), that would be the case because modifications to the file can be mapped back to the file through a push/commit

I have seen "atomic saving" be used to mean somewhat different things, but for the most part it seems to mean what we are doing here (Geany wiki, 15 year old stackoverflow thread, etc...). A more efficient saving mechanism using diffs might be interesting, but would probably be very complex to implement and then have to deal with forward- and backward-compatibility...

That being said, we should maybe tinker a bit more with the implementation as for instance metadata, permissions, and symlinks are not handled...

[anesthetice]

@Doublonmousse Apologies for the delay, let me know what you think

[anesthetice]

Atomic FS was split-off into it's own branch (+PR), see #1678