feat: Add on_stream to agents as tools (proposed alternative API design)

[ihower]

Based on PR #2169. I propose an alternative API design.

The on_stream API is updated so it no longer wrap events in AgentToolStreamEvent.
It now receives the raw StreamEvent and the caller agent’s tool invocation ToolContext.

To let on_stream know which agent and tool triggered the nested run, ToolContext is extended to include a new caller_agent field.

Reasons

• Agents do not need to know in advance that they might be used as sub-agents.
• The same on_stream handler function can work for both direct runs and agent-as-tool runs. In other words, the same streaming code for an agent can be reused whether you run the agent on its own or invoke it as a sub-agent. If needed, the caller_tool_context also lets developers know that the stream is happening inside another agent’s tool invocation and provides access to the caller agent’s context information.
• Passing the raw StreamEvent keeps the API simpler and removes the need for the extra AgentToolStreamEvent wrapper.

The example agents_as_tools_streaming.py now shows two cases:
Scenario 1 (direct streaming) and Scenario 2 (agent-as-tool streaming).

[seratch]

Thanks for this suggestion, but I think having a single dict enables us to enhance the argument list more easily. This object currently has only agent's name and tool's call_id but these properties could be richer to have other metadata as well (like Rohan mentioned having Agent instead in my PR).