fix: convert functionResponse parts to Spring AI ToolResponseMessage

[hemasekhar-p]

Please ensure you have read the contribution guide before creating a pull request.

Link to Issue or Description of Change

1. Link to an existing issue (if applicable):

• Closes: Tool calling problem when using Spring AI #1423

Problem:
When using Spring AI as the model provider in ADK and a tool call is executed, the tool execution result (FunctionResponse part inside ADK Content) was dropped during Prompt construction in MessageConverter.java. On the second request to the LLM, the prompt sent an AssistantMessage containing tool_calls followed by a user message missing the matching tool_call_id response messages. This caused provider API validation failures across LLM providers (e.g., OpenAI HTTP 400 Bad Request: "An assistant message with 'tool_calls' must be followed by tool messages responding to each 'tool_call_id'"). Furthermore, MessageConverter generated empty UserMessage("") instances on tool response turns, causing additional validation failures on strict providers

Solution:

1. Updated MessageConverter.java (handleUserContent) to convert part.functionResponse() into Spring AI ToolResponseMessage
2. Updated handleUserContent logic so that a UserMessage is only created when non-empty text/media exists or when toolResponseMessages.isEmpty(), preventing empty UserMessage("") instances during tool response turns
3. Updated MessageConverterTest.java to assert ToolResponseMessage generation

Unit Tests:

• I have added or updated unit tests for my change.
• All unit tests pass locally.

Please include a summary of passed java test results.

Manual End-to-End (E2E) Tests:

Executed multi-turn tool execution flow with a Spring AI hello-time-agent sample using mock and live model drivers before and after fix to confirm fix works as expected or not.

Checklist

• I have read the CONTRIBUTING.md document.
• My pull request contains a single commit.
• I have performed a self-review of my own code.
• I have commented my code, particularly in hard-to-understand areas.
• I have added tests that prove my fix is effective or that my feature works.
• New and existing unit tests pass locally with my changes.
• I have manually tested my changes end-to-end.
• Any dependent changes have been merged and published in downstream modules.