weird on_messages and on_messages_stream abstract relationship in BaseChatAgent

[bio-mlhui]

In BaseChatAgent implementation, the default implementation for ```on_messages`` is blank:

    @abstractmethod
    async def on_messages(self, messages: Sequence[ChatMessage], cancellation_token: CancellationToken) -> Response:
        ...

and the default implementation for on_messages_stream is based on on_messages:

    async def on_messages_stream(
        self, messages: Sequence[ChatMessage], cancellation_token: CancellationToken
    ) -> AsyncGenerator[AgentEvent | ChatMessage | Response, None]:
        response = await self.on_messages(messages, cancellation_token)
        for inner_message in response.inner_messages or []:
            yield inner_message
        yield response

However, in AssistantAgent, the relationship is reversed: the implementation of on_messages is based on on_messages_stream:

    async def on_messages(self, messages: Sequence[ChatMessage], cancellation_token: CancellationToken) -> Response:
        async for message in self.on_messages_stream(messages, cancellation_token):
            if isinstance(message, Response):
                return message
        raise AssertionError("The stream should have returned the final result.")

    async def on_messages_stream(
        self, messages: Sequence[ChatMessage], cancellation_token: CancellationToken
    ) -> AsyncGenerator[AgentEvent | ChatMessage | Response, None]:
     many_codes_following
            )

I think it is more elegant to reverse their relationship in BaseChatAgent. When the developer want to cutomize a new BaseChatAgent, the developer only needs to instantiate the on_messages_stream method.

[ekzhu]

The thought was it was just easier to implement on_messages. If someone were to implement on_messages_stream, then it would be on them to also add on_messages also, which is basically boilerplate code at that point.

A potential simplification is to have a utility private method as part of BaseChatAgent that implements on_messages with an existing on_messages_stream implementation. Just for convenience.