feat(tls): add an async-tls-rustls-no-provider backend

[stephane-segning]

Closes #1.

What this does

Adds a third async rustls backend, async-tls-rustls-no-provider, that takes its
crypto provider from the process-wide default the application installed instead
of one this crate hard-selects.

Why it needed code, not just a feature

My issue proposed this as a Cargo.toml one-liner. Reading the crate, that was
wrong — the provider is chosen in code, not only in features:

// build_rustls_ring_transport
let tls_config = build_rustls_tls_config(
    TlsBackend::RustlsRing,
    rustls::crypto::ring::default_provider(),
    tls_options,
)?;

with a parallel pair for aws-lc-rs and a #[cfg(not(...))] stub each. So a
no-provider path needs its own TlsBackend variant, its own builder pair, a
dispatcher arm, and an entry in the compile_error! guard that enforces "one
async-tls-* feature must be enabled".

TlsBackend is already #[non_exhaustive], so the new variant is semver-minor
for downstream crates.

The one design decision worth reviewing

The provider is fetched, not assumed:

let provider = rustls::crypto::CryptoProvider::get_default()
    .cloned()
    .ok_or_else(|| Error::TlsBackendInit { backend: ..., message: ... })?;

rustls::ClientConfig::builder() would have been shorter, but it panics when
no provider is installed — which is precisely the situation this feature makes
reachable. A returned TlsBackendInit naming install_default seemed the only
defensible behaviour for a library. Happy to change it if you disagree.

One change outside the async path

Two matches in src/blocking_client/transport.rs are exhaustive over
TlsBackend — #[non_exhaustive] constrains downstream crates, not this one — so
they stopped compiling under any blocking feature once the variant existed.

Both are handled explicitly rather than with a _ arm: backend_is_available
returns false, and build_sync_tls_config returns TlsBackendUnavailable, since
there is no ureq counterpart. That keeps the property that adding a future
backend produces a compile error here instead of silently falling into a catch-all.

Verification

Run on the pushed commit, not just locally at some earlier point:

check	result
cargo check — no-provider / ring / aws-lc-rs / native / blocking-ring / --all-features	all pass
cargo fmt --check	clean
cargo clippy -- -D warnings, new feature and defaults	clean
cargo test --no-run	builds

The claim that actually matters, with a positive control so it cannot pass
vacuously:

# production graph only, new feature
$ cargo tree --features async-tls-rustls-no-provider -e normal -i ring
warning: nothing to print.
$ cargo tree --features async-tls-rustls-no-provider -e normal -i aws-lc-rs
error: package ID specification `aws-lc-rs` did not match any packages

# same query, ring feature - proves the query detects ring when present
$ cargo tree --features async-tls-rustls-ring -e normal -i ring
ring v0.17.14

-e normal is deliberate: ring is still reachable as a dev-dependency via
rcgen, identically on every feature, which is unrelated to backend selection.

Context

We run an image-processing service that removed every C and C++ dependency and
enforces it in CI. s3 builds on reqx and
already signs SigV4 with the pure-Rust graviola, so this feature is the last
thing between that crate and a fully pure-Rust S3 client. There is also a FIPS
case: aws-lc-rs's FIPS mode needs the same escape hatch.

Precedent for the shape: reqwest ships rustls-no-provider, and ureq ships
one that this crate already depends on in blocking-tls-rustls-aws-lc-rs.

Notes

The issue offered an alternative shape — one async-tls-rustls feature plus
separate provider features, which would be cleaner but breaking. I built the
additive version since it is non-breaking; say the word if you would rather have
the other and I will rework it.

No CHANGELOG entry, since git cliff generates it from commits at release time.