[Feat]: Improve client auth handling

### Is your feature request related to a problem? Please describe.

Agents declare their authentication requirements via the [`security_schemes` and `security`](https://github.com/a2aproject/a2a-python/blob/main/src/a2a/types.py#L1807) fields in the AgentCard. Skills can also [declare required security](https://github.com/a2aproject/a2a-python/blob/main/src/a2a/types.py#L167).

Clients are responsible for understanding how to fulfill these authentication requirements. As of now, this is effectively left to the developer to roll this code themselves. However, in some cases, the SecuritySchemes object contains enough information to programmatically determine how to fulfill the auth requirements. We should provide a base implementation for this that handles common use cases (such as OAuth).

The [`AuthInterceptor` class](https://github.com/a2aproject/a2a-python/blob/main/src/a2a/client/auth/interceptor.py) class is a start, but we're missing pieces for easily using it. `AuthInterceptor` handles the work of placing the credential in the right HTTP header (if known). It's still up to the developer to set up a `CredentialService` and pass the `AuthInterceptor` in the right spots. We can do better.

### Describe the solution you'd like

Many auth schemes require, at minimum, some configuration in order to fulfill. For OAuth, if you want to generate access tokens on demand, you need a Client ID and Secret. For API Key authentication, you need the key to be sent. For mTLS, you need a client certificate to use. Once you have this, however, it's generally possible to handle the authentication with common code.

My idea for the interface is essentially:

1. Load up an object with a bunch of authentication configurations.
2. Provide this object to the [`ClientFactory`](https://github.com/a2aproject/a2a-python/blob/main/src/a2a/client/client_factory.py), perhaps via ClientConfig.
3. When a client is constructed, analyze the SecuritySchemes + security in the AgentCard to determine whether we have sufficient information to meet the authentication requirements for the agent.
4. If so, compose a credential handling object that wraps the logic needed to fulfill the authentication requirements and provide this to the client.
5. If not, we could raise a warning that we don't know how to fulfill the authentication for the agent. You can ignore this warning and continue, or treat this as an error and be unable to use the client.
6. When interacting with the client, authentication is handled as transparently as possible. There are cases where the code using the client needs to provide additional information, such as for OAuth Authorization Code access tokens.

I have not fully investigated how feasible this is or what the pieces I'm missing are. Authentication code is generally pretty complex, so for complicated cases I expect we'll need a lot of thought for creating an appropriate interface.

Here's a rough sketch of how the code could look:
```py
client_credential_manager = ClientCredentialManager()
# Methods for configuring well-known authentication types.
client_credential_manager.add_oauth_client(
id="google",
token_url="https://oauth2.googleapis.com/token",
authorization_url="https://accounts.google.com/o/oauth2/v2/auth",
client_config=(MY_CLIENT_ID, MY_CLIENT_SECRET),
use_authorization_code_flow=True,
)
client_credential_manager.add_mtls(
id="example-com-mtls",
certificate=MY_CLIENT_CERTIFICATE,
)
client_credential_manager.add_api_key(
id="cool-api-key",
host_domain="example.com",
api_key=MY_API_KEY,
)
# But generalized underpinnings to be extensible.
# Something like AuthScheme.matches(SecurityScheme) and AuthScheme.get_handler(AgentCard, SecurityScheme)
custom_auth_scheme = MyAuthScheme()
client_credential_manager.add_handler(
id="my-custom-auth",
scheme=custom_auth_scheme
)

client_config = ClientConfig(
# ... Normal config stuff,
credential_manager=client_credential_manager
)
client_factory = ClientFactory(client_config)
```

And using the client should be as transparent as possible:
```py
some_agent_card = AgentCard(
url="https://agents.example.com/magic",
# ...
security_schemes = {
"google_oauth": OAuth2SecurityScheme(
flows=OAuthFlows(
authorization_code=AuthorizationCodeOAuthFlow(
authorization_url="https://accounts.google.com/o/oauth2/v2/auth",
# ...
)
)
),
},
security=[{"google_oauth": []}, {}],
)

# Credential manager helps match and fulfill auth schemes.
client = client_factory.create(some_agent_card)
# Yay, it just works!
client.send_message(new_text_message("Hello!"))
```

Some additional thoughts:

- We should handle both patterns of statically configured credentials and dynamically sourced credentials. Users may want to use request-level context to choose what credentials are provided on a request.
- However, we should be able to know whether we have any chance at all of fulfilling auth requirements at client construction time.
- OAuth is a really big use case, so we should build out as much support for this as we can. This should include being able to retrieve access tokens stored in a secret manager or performing an authorization flow on demand.
- Our underlying abstractions should be pretty flexible -- be able to match an auth scheme against a SecurityScheme, and some kind of handler that alters outgoing requests to attach credentials. This gets a little complicated with our various transports -- JSON-RPC and REST use HTTP headers, gRPC uses Metadata. Something more esoteric might not have an equivalent side-channel, so there might be some interaction with `ClientTransport` implementations.

### Describe alternatives you've considered

We currently have some initial support for `ClientCallInterceptor`s. This was built with auth in mind, but hasn't been integrated as smoothly as we'd like and it isn't clear how it works with all transports. We may use `ClientCallInterceptors` and `ClientCallContext` under the hood, but it should be largely transparent to users.

There's some initial auth support in src/a2a/client/auth, but it's not as extensive as what I'm proposing. It's the right start, but needs to be cleaned up and better structured.

### Additional context

_No response_

### Code of Conduct

- [x] I agree to follow this project's Code of Conduct

Commencez par lire la classe AuthInterceptor existante dans src/a2a/client/auth/interceptor.py et ClientFactory dans src/a2a/client/client_factory.py. Comprenez comment les schémas de sécurité de AgentCard sont définis dans src/a2a/types.py. L’objectif est de concevoir un ClientCredentialManager capable de faire correspondre les schémas de sécurité et de joindre automatiquement les identifiants. Vérifiez comment les différents transports (HTTP, gRPC) gèrent l’authentification. Une preuve de concept consisterait à étendre ClientConfig pour qu’il accepte un gestionnaire d’identifiants et à modifier le flux de création du client afin d’injecter les intercepteurs appropriés.

Rédigé par le modèle d'indexation à partir du texte de l'issue.