Add safe Rust zstd decoding backend

[Shnatsel]

Pros: 100% safe Rust. No memory safety bugs, no C toolchain required

Cons: ~3x slower than libzstd

Future compatibility notes

The safe Rust impl has no encoding support. That's fine for now since the crate doesn't support encoding Zstd anywyay. When encoding is implemented, we'll have to limit it to the zstd feature only, which should be trivial.

Trifecta Tech Foundation is starting work on a Rust drop-in replacement for libzstd, similar to zlib-rs. When that's ready to use, I expect it to replace the zstd feature, and this option to remain available.

[197g]

I'd gladly add it optionally, similar to rustls being an option for SSL crates. @KillingSpark If you have the time to chime in and maybe some words on the integration?

[197g]

I find it a little odd to get an error already from construction that is related to the contents rather than the parameters. Well, a bit hypocritical, considering I'm currently fixing us having the same mistake in Decoder::new.

[fintelia]

They return errors in the new method for the same reason we currently do: that's where header parsing happens

[fintelia]

Another naming option would be zstd and zstd-native which parallels how we name the two AVIF features in the image crate

[Shnatsel]

There is a documented caveat in the ruzstd streaming decoder: it only decodes a single frame from the stream, while Zstd streams can contain multiple frames.

But multi-frame files are relatively uncommon and the fix should be committed upstream into ruzstd instead of complicating callers, so I don't think that would change this PR in any way.

[KillingSpark]

Hi everyone,

the code in the PR looks good. A few things:

1. Technically the ruzstd has encoding support since a few months. Its not really configurable but it does compress somewhat well. Performance wise it's also lagging behind the C implementation. Whether this is good enough for this crate I can't really say. It's tested and fuzzed and it's ready for use, if these tradeoffs are acceptable.
2. The multi-frame issue is very annoying. I have not yet found an API that makes me happy. The format also allows skippable frames. Just providing an API that skips these without providing a possibility to interact with the contents seems bad. Always having to pass handlers and stuff for these bloats the API in when most people don't care about these frames. Anyways, yeah right now ruzstd just passes that responsibility to the user which also isn't ideal. As I said: its annoying.
3. Ruzstd has a small portion of unsafe code because the std VecDeque doesn't have a extend_from_within which is needed for an efficient implementation.