Document feature flags using document-features crate

[Copilot]

The crate's feature flags, particularly the internal any_impl and any_zlib markers, lacked documentation. This PR adds comprehensive feature documentation that appears in cargo doc output.

Changes

• Added document-features integration: Uses document-features crate to auto-generate feature documentation from Cargo.toml comments
• Documented internal markers:
  • any_impl: Marker ensuring a backend is selected (auto-enabled by all backends)
  • any_zlib: Marker for C-based zlib backends (auto-enabled by zlib, zlib-ng, zlib-ng-compat, cloudflare_zlib)
• Documented all user-facing backends: Added descriptions for rust_backend, zlib-rs, zlib, zlib-ng, zlib-ng-compat, zlib-default, cloudflare_zlib, and miniz-sys

Result

Feature documentation now appears in the crate docs under a dedicated "Feature Flags" section:

[dependencies]
# Choose the fastest pure Rust backend
flate2 = { version = "1.1", features = ["zlib-rs"], default-features = false }

# Or use the default safe Rust backend
flate2 = "1.1"  # Uses rust_backend (miniz_oxide)

Original prompt

Find out what the any_impl and any_zlib features mean, and document them in detail.
Use the https://crates.io/crates/document-features crate (and set it up) so that documentation for the feature toggles is build into the cargo doc build.
While at it, document all user facing features as well.

---

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.

[Byron]

I made document-features optional and reordered the docs a bit. They now look like this:

Could @folkertdev and @jongiddy take a look and double check the docs? With your corrections and improvements, I think we will get to the next step quickly, which is to find a way to ensure #517 doesn't happen again (and is fixed with the next release).

Thank you 🙏.

[Byron]

Looks good to me now, and with the documentation of the internal features I think a follow-up could expand on that, namely to explain why the split of features into any_impl and any_zlib is needed.

(Maybe it's also expected that #517 doesn't expose certain types anymore with zlib-rs)

[jongiddy]

The doc changes look very nice.

One unusual aspect of the features is that you can select a different backend without setting default-features = false to disable the default backend. Last time I checked, you could actually select any number of backend features and there is a priority order for which backend will be selected. I believe the backend selected is the first selected of these:

• zlib-ng
• zlib-rs
• cloudflare_zlib
• miniz_oxide

Also, not completely related to the doc changes, now that we have 2 Rust backends, using miniz_oxide rather than rust_backend as the preferred feature name would seem less ambiguous. Maybe rust_backend should be documented to select a Rust backend, with no guarantee of which one?

[Byron]

Thanks for sharing @jongiddy! I have incorporated your notes, or so I hope, and the docs now render like so:

I probably shouldn't have force-pushed though, and will try to avoid it in future revisions.

@jongiddy If you would approve, I'd merge this, knowing that changes to the zlib-rs docs can be made later as @folkertdev and I tackle #520 .