Implement Web3Signer-compatible `Keystore`

Today the client only provides `FilesystemKeyStore` for handling keys. This is a pretty barebones key management tool.
Production operators often can't keep signing keys on disk, which leaves them responsible of implementing `Keystore` / `TransactionAuthenticator` themselves. Infra teams would typically want to use KMS/HSM systems such as AWS KMS, Azure Key Vault, HashiCorp Vault, etc., with signing performed remotely. Such is the case of the Gateway team that builds the Agglayer integration (some code [here](https://github.com/gateway-fm/miden-agglayer/blob/49f84c4e075d087a3e196837839891b9390ff379/src/miden_client.rs#L806-L817), [here](https://github.com/gateway-fm/miden-agglayer/blob/49f84c4e075d087a3e196837839891b9390ff379/src/remote_signer.rs), and [here](https://github.com/gateway-fm/miden-agglayer/blob/49f84c4e075d087a3e196837839891b9390ff379/src/proxy_keystore.rs#L236-L274)).

We should look into providing such functinoality as a useful first-party key-management backend for the client.

For providing signatures, we could integrate with Web3Signer which is compatible with the typical production key management services.
`Web3SignerKeyStore` (name TBD) should implement `Keystore`/`TransactionAuthenticator` and would be in charge of connecting to a user-provided and user-configured instance of Web3Signer which in turn would be in charge of signing.

```rust
let keystore = Web3SignerKeyStore::connect("http://127.0.0.1:9000", config).await?;
let client = ClientBuilder::new()
.authenticator(Arc::new(keystore))
...
```

Some notes:

- We should integrate the keystore with `ClientBuilder`
- Initially I think we only care about Web3Signer `eth1` API only, so only `EcdsaK256Keccak` accounts
- Falcon512accounts are out of scope, since Web3Signer and mainstream KMS providers do not support them
- In the agglayer codebase there is no key creation nor export. This is by design, but we can see about potentially refactoring the trait if needed. i.e., key management and signing are both enforced by `Keystore` but we could fully split them though this comes with its own consequences
- We should make it `no_std` compatible, unless there is a good reason not to
- We probably want to make this its own crate, but not a strong opinion

Look at the existing FilesystemKeyStore in the codebase to understand the Keystore and TransactionAuthenticator traits. Review the linked agglayer code for remote signing examples. The new Web3SignerKeyStore needs to connect to a Web3Signer instance, implement the signing methods for EcdsaK256Keccak accounts, and integrate with ClientBuilder. Ensure the implementation is no_std compatible. Start by setting up a local Web3Signer to test against.

由索引模型根據 Issue 內容生成。