refactor(core): route reqsign send via accessor http client

[Xuanwo]

Which issue does this PR close?

Closes #.

Rationale for this change

Services that use reqsign currently wire signing and credential-fetch traffic through a global default reqwest client. This bypasses accessor-level HTTP client injection and makes reqsign traffic inconsistent with OpenDAL's HTTP abstraction.

Since reqsign 3.0.0 is now available, this PR updates the integration to the new API shape and keeps the accessor-driven HTTP path working across native and wasm targets.

What changes are included in this PR?

• Add AccessorInfoHttpSend in opendal-core HTTP utilities.
• Implement reqsign_core::HttpSend for:
  • HttpClient
  • AccessorInfoHttpSend (delegates to AccessorInfo::http_client() at send time)
• Migrate reqsign users to this adapter in:
  • s3, gcs, oss, obs, cos, azblob, azdls, azfile
• Upgrade reqsign dependencies used by core services to 3.0.0.
• Update service-side reqsign builder calls to the 3.0.0 API.
• Remove GCS local workaround providers that are now built into reqsign-google 3.0.0.
• Switch S3 endpoint normalization from reqwest::Url to url::Url, and remove the direct reqwest dependency from opendal-service-s3.
• Update core/Cargo.lock accordingly.

Validation:

• cargo fmt --check
• cargo check --all-features
• cargo clippy --all-targets --all-features -- -D warnings
• cargo build --target wasm32-unknown-unknown --no-default-features --features='services-azblob services-gdrive services-opfs services-s3 layers-metrics' --locked

Are there any user-facing changes?

Yes.

Services using reqsign now send signing and credential-fetch HTTP requests through the accessor's HTTP client configuration, so injected clients are respected consistently. No public API changes.

AI Usage Statement

Implemented with Codex (GPT-5) in the local repository, with human review before PR submission.

[tisonkun]

Follow up a bit at #7235.

Generally LGTM. Thanks!

[Xuanwo]

Need to address wasm build failure