Document backend differences in compression levels

[Shnatsel]

Now with more details about compression levels in various backends!

We should probably fix the weird behavior of miniz_oxide for level 0, but this PR at least documents the current state, which should be an uncontroversial first step.

[Byron]

Wonderful, thanks so much!

[fintelia]

I don't think these claims are accurate.

This playground example demonstrates that miniz_oxide level 0 results in an uncompressed output, even though the input data was easily compressible. Could this claim have been a misinterpretation of Frommi/miniz_oxide#156 which was noting that level 0 was slow, not making a claim about correctness?

And I haven't been able to find any indication that output produced by miniz_oxide level 10 is non-compliant. Nothing in the implementation suggests that the bitstream won't be any different from lower levels and when I tried feeding output from level 10 compression into libz_sys it decoded fine. The linked PR cites a comment stating that level 10 is "not zlib compatible, and may be very slow" but I think that is saying that having a level 10 isn't compatible with the assumption that 9 is the highest. Not that using level 10 results in output that cannot be decoded by other libraries.

[Shnatsel]

@oyvindln could you take a look and see if I've misinterpreted miniz_oxide documentation? The docs on flate2 are very visible so I'd like to get this right.

[oyvindln]

@fintelia is correct yeah. I think the "not zlib compatible" thing in the original miniz doc just means that zlib doesn't have a corresponding level 10 you can't put in 10 as a level if using zlib (not that zlib levels correspond exactly to miniz levels anyhow as there are some slight differences in algorithm). It just does even more checks than level 9, it doesn't produce any different stream otherwise.

level 0 means no compression, it's noted in the miniz_oxide documentation, same with level 10.