[Agents] Post V1.0 Work

### What would you like to be added?

This FR requests the implementation of a new SubAgent class: A re-usable component that manages LLM driven tool orchestration.

This is applicable in the following contexts:
* Allowing a Tool to iteratively solve a problem it encounters. For example, the EditTool using the SubAgent to find a better match string in the case of stale data; or a future "update docstrings" tool, which may call multiple existing tools to find files, edit them and test them.
* Agentic Scopes - Allowing a Tool to be run in an isolated mode - If a tool doesn't manage its' own self healing, and instead expects to do that on the main thread, a SubAgent can be created, which clones the MonoAgent history, executes the tool, and only returns the successful response back to the main thread ()

This FR suggests the most direct path towards implementation would be:
* Create a wrapper around GeminiChat which can drive the GeminiChat::sendMessage*(..) functions either in a nonInteractive, or Interactive function
* Allow a list of filtered tools to be passed to the GeminiChat ContentGenerator::generateContentStream(..) function, so that only a subset of tools may be considered during execution
* Allow a custom system prompt to be provided for GeminiChat to use.
* Allow variable output via a set of private tools that the Agent can use to calculate response data to be accessed via the Caller of the SubAgent.

### Why is this needed?

Currently, GC uses a _mono-agent_ architecture; One SWE Agent which is responsible for all work across the application. While this approach is powerful in its' own right, there's some challenges that it presents:

* Higher Memory Rot - Given that all self healing operations occur in a single History object, there's a higher chance of hallucinations over time as the context history becomes more complex and full of conflicting / stale information. Consider the situation where a file-read occurs, then 2-3 edit attempts that fail, followed by a success. There now may be 5 examples of the same block of code in history memory, which can lead to confusion.
* Lack of SmartTools - The GC Codebase currently has a single agent implementation (GeminiClient + GeminiChat), which means that tools themselves cannot currently support agentic loops in their processing (e.g. recovering from a failure, or orchestrating private tools to execute a task). Further, no other part of the application can engage in Agentic patterns, since there's no primitive to leverage to do so.

### Additional context

Areas of open discussion:
* **Tool permissions** - There's some open discussion that needs to be had about how tool-based permissions work inside subagents. (For example, if you've given ToolX permission to write-always, does that permission also follow forward to when that tool is used inside of a subagent?)
* **System prompt re-use** - The SubAgent can accept a custom system prompt to drive work, but it may be viable to leverage existing portions of the existing MonoAgent prompt. This is a challenge because the current Mono-Agent system prompt is _powerful_ but also _static_: It currently does not provide a mechanism to be re-used by sub agents, or be broken up in the case of available tools changing. In this case, an ideal solution for SubAgents orchestrating the existing tools may require breaking up prompts.ts to provide a sub-agent the ability to grab examples & multi-shot snippets for a specific tool it is using (which is currently hard-coded into the main prompt).

Important Notes:
* This FR _only_ discusses the addition of the SubAgent primitive, and is not intended to be a solution to larger discussions around mass orchestration of Agents, or their coordinated efforts towards task resolution (e.g. "why not use existing agent-orchestration library X?"). Those are significant architecture conversations that need to happen across the team, as orchestration is a higher level discussion to the SubAgent primitive proposed here.
* This SubAgent suggestion is intended to be _blocking_, in that the calling thread blocks until SubAgent execution is finished - Discussions regarding async subagent execution & scheduling (and the impact that has on ChatHistory ) is left for a future discussion.