new feature: Add a FIPS-ready Rust crate profile

## 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.

Start with the existing reqwest-rustls-no-provider-tls feature and the documented rustls FIPS provider initialization path. Review the Rust crate and service dependency graphs for S3, Azure Blob, and GCS, then define the documentation, example, and CI checks described here. Done means the FIPS-ready source boundary is documented, the provider setup is demonstrated, representative dependency checks exist, and unsupported services are identified for follow-up.

Written by the indexing model from the issue text.