Enable customizing Zstd decoding parameters.

[quantatic]

closes #284

This PR updates the minimum zstd version to 0.13.1, in order to make DParameter Clone+Copy.

[NobodyXu]

I think we should propagate the error from zstd?

[quantatic]

I'm not necessarily opposed to this, though in the interest of consistency, it appears that this library chooses to panic on construction errors for other encoders/decoders:

• async-compression/src/codec/zstd/encoder.rs

  Line 18 in 7c2d530

  pub(crate) fn new_with_params(level: i32, params: &[crate::zstd::CParameter]) -> Self {

• async-compression/src/codec/xz2/encoder.rs

  Line 23 in 7c2d530

  Xz2FileFormat::Xz => Stream::new_easy_encoder(level, Check::Crc64).unwrap(),

[NobodyXu]

That's unfortunate, maybe we should add a try_ variant for these APIs?

cc @robjtede what's your thoughts on this?

[robjtede]

I think typically panics are acceptable when it comes to "programmer error" and I really, really don't expect decoding parameters to be user-input, or anything other than hardcoded. Therefore it's fine to me that this can panic. It's a fairly unrecoverable error for both these unwraps.

[quantatic]

This change is technically semver-compatible with only a minor version bump on next release, though it's unclear to me how this would be compatible with a crate that locks zstd = "=0.13.0. Is such a change still considered semver-compatible?

[NobodyXu]

This change is technically semver-compatible with only a minor version bump on next release, though it's unclear to me how this would be compatible with a crate that locks zstd = "=0.13.0. Is such a change still considered semver-compatible?

Given that we don't expose any implementation detail, I think it can be said as semver-compatible API-wise

[robjtede]

Is such a change still considered semver-compatible

yes

nice change, thanks for the work :)