fix(features): don't enable rustls/default from rustls-ring

[EddieHouston]

Fixes #219.

The rustls-ring feature used "rustls/ring" (without ?), which also activates the crate's explicit rustls feature, and that feature enables rustls/default, i.e. the aws-lc-rs provider. So a downstream asking for use-rustls-ring (expecting ring only) ended up with both providers enabled on rustls:

electrum-client feature "rustls"
  └── electrum-client feature "rustls-ring"
      └── electrum-client feature "use-rustls-ring"

With both providers compiled in, any crate in the same binary relying on rustls's process-default provider panics on first TLS use ("exactly one of aws-lc-rs and ring"). electrum-client itself is unaffected (it selects its provider explicitly), but we hit this in lwk after bumping electrum-client 0.21 -> 0.25: the shared rustls went from ring-only to ring + aws-lc-rs and an unrelated tokio-tungstenite connection started panicking.

Before (on master, --no-default-features --features use-rustls-ring):

rustls v0.23.41 aws-lc-rs,aws_lc_rs,default,log,logging,prefer-post-quantum,ring,std,tls12

After:

rustls v0.23.41 log,logging,ring,std,tls12

The default (rustls/aws-lc) feature path is unchanged. Note this is behavior-visible for any downstream that unintentionally relied on the leak to get aws-lc-rs while only enabling use-rustls-ring; they would need to enable the aws-lc provider themselves.

[EddieHouston]

same zeroize MSRV as seen in #219