Update the coordinated RustCrypto dependency stack

[lthiery]

Builds on the direction discussed in #502, particularly the recommendation to update the full RustCrypto family together rather than carry duplicate hybrid-array/crypto-common/digest/signature generations.

This updates:

• signature 2 -> 3
• hmac 0.12 -> 0.13
• sha2 0.10 -> 0.11
• p256/p384 0.13 -> 0.14
• ed25519-dalek 2 -> 3
• rsa 0.9 -> 0.10.0-rc.18
• rand 0.8 -> 0.10

The implementation changes are API migrations only: HMAC no longer resets a freshly cloned state, RSA uses BoxedUint, ECDSA uses the updated infallible recoverable-signature API, and the Ed25519 example uses the current RNG API.

The RSA prerelease requirement is an ordinary Cargo caret requirement. It permits newer prereleases of 0.10.0 and automatically permits the final 0.10.0 and later compatible 0.10.x versions once published. An existing application lockfile still requires its normal dependency update cycle.

Validated locally:

• cargo fmt --check
• cargo check --all-features
• cargo clippy --all-targets --features rust_crypto -- -D warnings
• cargo clippy --all-targets --features aws_lc_rs -- -D warnings
• cargo test --features rust_crypto
• cargo test --features aws_lc_rs

Related: #495 and #502.

[arckoor]

Let's not depend on a rc version

[lthiery]

I did take a look at keeping rsa on stable, but the cost is significant.

rsa 0.9 is built against the previous generation of digest/signature/rand traits, so keeping it alongside the updated stack means Cargo.toml carries renamed duplicates (sha2 0.10 + signature 2 + rand_core 0.6 next to their new versions)... so the tree ends up with 14 crates duplicated across two generations (sha2, digest, signature, crypto-common, block-buffer, const-oid, der, spki, pkcs8, pem-rfc7468, rand, rand_core, getrandom, cpufeatures).

The wasm build also gets both getrandom 0.2 and 0.4, each needing its own backend feature in CI. That is the situation #502 recommended avoiding.

rsa has been in its 0.10 pre/rc cycle since early 2024, so IMO, I would go for accepting the rc in favor of getting an unmitigated generational bump.

And then from the security angle, RUSTSEC-2023-0071 (Marvin) is flagged against all rsa versions, but the fix can only ever land on 0.10: it's a breaking change (the bignum backend swap), so 0.9 can't get it. Part of it is already in this rc, and when the advisory is resolved on 0.10, the caret requirement here means downstreams pick it up with a plain cargo update, no release needed on this crate.

Generally, I'd stay way from rc but it seems like a pragmatic step in this case.