[Feat]: Support JSON-RPC Responses for Decoupled Pub/Sub Push Communication in Message-Driven Architectures

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

The current implementation of the A2A Python SDK, when used as an agent in a message-driven architecture (e.g., handling requests pushed via Google Pub/Sub), only validates and accepts JSONRPCRequest objects on its primary HTTP 'POST' route.

In this architecture, an agent receives a request from a message broker (e.g., Pub/Sub push subscription), processes it, acknowledges the broker with a standard HTTP response, and sends the real, decoupled response back to the requesting service's inbound message queue.

If the requesting service is also an agent built with the same A2A Python SDK, it needs to receive a JSONRPCResponse. Since the receiving agent's primary 'POST' route strictly expects a JSONRPCRequest format via the Pydantic model validation, the inbound JSONRPCResponse is rejected, preventing the successful completion of the message exchange.

### Describe the solution you'd like

We need to enable the SDK to correctly receive and process JSONRPCResponse objects on an agent, facilitating decoupled, asynchronous, push-based communication.

We propose discussing two possible solutions:
1. Loosen Model Validation for Combined Input: Modify the Pydantic model validation on the main 'POST' route to accept a combined input of either a JSONRPCRequest or a JSONRPCResponse(e.g., checking against a union type like JSONRPCRequest | JSONRPCResponse). This would allow responses to be delivered via the existing primary request route.
2. Introduce a Dedicated Response Route: Implement a new, dedicated HTTP endpoint (e.g., /response or /push_response) specifically for receiving and handling decoupled JSONRPCResponse objects.

### Describe alternatives you've considered

_No response_

### Additional context

This issue is critical for agents using the A2A Python SDK within environments where asynchronous, Pub/Sub push-based communication is the standard, as it currently blocks the ability to receive the final response successfully.

### Code of Conduct

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