.Net: Feature/gemini function parts format

[abbottdev]

Motivation and Context

1. Why is this change required?
   It appears that there's a quirk to how Gemini handles tool call results in it's API. The tool responses need to be present in the same chat item as the tool requests - rather than adding them individually as separate chat history items.
2. What problem does it solve?
   This appears to fix (at least in my use case) the error whereby you receive:

{
  "error": {
    "code": 400,
    "message": "Please ensure that the number of function response parts is equal to the number of function call parts of the function call turn.",
    "status": "INVALID_ARGUMENT"
  }
}

4. Which appears to happen when an SK response auto invokes > 1 tool. When it's a single tool result the API appears to handle the response gracefully.
5. .Net: Bug: Google Gemini plugin call fails after SK version > 1.0.55 : "Error: Ensure number of function response parts is equal to the number of function call parts of the function call turn." #12823
6. .Net: Bug: Gemini - 2 parallel plugin call exception: number of function response parts is equal to the number of function call parts of the function call turn #12528
   -->

Description

Google Gemini expects the function responses to be grouped together in a single message rather than split across multiple separate messages with role "function". By adding a batch tool result overload to the GeminiChatMessage we can correctly parse the multiple parts of the function call into their respective function parts.

Contribution Checklist

• The code builds clean without any errors or warnings
• The PR follows the SK Contribution Guidelines and the pre-submission formatting script raises no violations
• All unit tests pass, and I have added new tests where possible
• I didn't break anyone 😄

FYI @stephentoub (As I see you're working in the Gemini connector recently)

[abbottdev]

@microsoft-github-policy-service agree company="Kroll"

[rogerbarreto]

@abbottdev Thank you for the contribution!

Can as part of this change you also add an Manual Integration test that covers one of the reproduction code in the issue?

A simple example similar to the ones we have in the GettingStarted using Time and Weather could suffice to validate the double function calling updates do work directly with API calls.

Thanks!