new feature: Add a FIPS-ready Rust crate profile

[Xuanwo]

Feature Description

Add a FIPS-ready Rust crate profile for OpenDAL.

The goal is to make OpenDAL usable by downstream Rust applications that need to run with FIPS-approved cryptography, without claiming that the OpenDAL crate itself is a FIPS 140-2/140-3 validated module. FIPS validation applies to concrete cryptographic modules, versions, build environments, and runtime modes; a Rust crate can only provide an auditable source-level path that does not force non-FIPS cryptography into the final application.

Problem and Solution

Some OpenDAL users need to build applications for regulated environments. Today OpenDAL already exposes reqwest-rustls-no-provider-tls, which lets the downstream binary install its own rustls::CryptoProvider, but the overall FIPS story is not documented or verified end to end.

We should add an explicit FIPS-ready profile that covers:

• Document the support boundary: OpenDAL provides a FIPS-ready source profile, while the downstream application remains responsible for using a validated cryptographic module and an approved runtime mode.
• Keep TLS provider selection at the application boundary by documenting reqwest-rustls-no-provider-tls and the expected rustls FIPS provider initialization path.
• Audit OpenDAL and service crates for direct cryptographic operations, especially request signing, JWT/RSA signing, HMAC, SHA, MD5, SHA1, and checksum paths.
• Move security-sensitive signing/hash operations used by OpenDAL and reqsign onto a FIPS-capable backend, or mark the affected service as unsupported in the FIPS profile.
• Classify protocol-required non-security checksums such as Content-MD5, ETag MD5, and CRC32C so they are not presented as cryptographic protection.
• Add CI checks for the FIPS profile dependency graph, for example denying accidental ring, non-FIPS aws-lc-sys, or direct non-approved crypto backends in security-sensitive paths.
• Publish a support matrix for services and bindings, starting with the Rust crate. Other language bindings can be handled separately because binary artifacts have different release and audit requirements.

A first implementation can focus on Rust crate users only:

1. Add docs that show how to depend on OpenDAL with the FIPS-ready profile.
2. Add a small example that installs the rustls FIPS crypto provider before constructing OpenDAL clients.
3. Add dependency-tree checks for representative services such as S3, Azure Blob, and GCS.
4. File follow-up issues for services whose signing protocol cannot be supported under the profile.

Additional Context

This issue is intentionally scoped to a Rust crate/source profile. Publishing FIPS-specific wheels, jars, npm native artifacts, or containers would require a separate release profile because those artifacts fix the final dependency graph and runtime environment.