Purpose:
---------
Allow the agents to update records.
Agents will always show a preview of the changes that will be done and
require the user to confirm the suggested changes before updating the
records.


To achieve this the agents framework has been refactored:

The previous LLMApiService was entirely stateless, resulting in several
significant functional and efficiency issues. This PR introduces the
concept of an AI Session to hold the complete conversation history, thus
resolving these problems and enabling new features like user-interactive
tools.

The primary issues resolved are:
- Redundant tool calls: tools and their results were not included in the
history, resulting in the LLM calling the same tool with the same args
multiple time for the same context.
- Inefficient reasoning: LLMs with reasoning capabilities would restart
their thought processes on every new message because thinking signatures
were lost.
- Missing interactive tools: It was impossible to design tools that
required pausing and confirmation from the user mid-flow.

Technical Changes:
------------------
- Added a transient `ai.session` model, designed to store the complete history
of user and model messages, including tool calls, tool responses, and model
thinking signatures. This model is designed to be overridable to support
different providers (e.g., ai.session.openai and ai.session.google).

- The ai dict available inside every tool has new capabilities
It carries (among others)
  - a `state` dict which enables tools to store and retrieve data across
  multiple tool calls
  - a `tool_request_message` used to store a message that will be shown to request usage of the tool to the user
  - a `tool_request_confirmed` boolean used to check if the user confirmed usage of the tool
  - the 'res_model' and 'res_id' of the record the session is linked to (when session is opened from a  form view for example)
  - a `final_message` string allowing to "short-cut" and post a response
  as if it was the LLM's answer

- Record information has been removed from the instructions to prevent
prompt injection, and because the record data is dynamic. 
Instead, the record info is added as a context message along with the user
message (that context message is not stored in the session history)

- The "Is Ask Ai" and related code has been removed. Instead of searching
  for a potential agent that could do the "Ask AI" job, we use the one associated
  with the "systray" interface key for consistency 

Usage:
-------
There are several ways to query a LLM depending on the needs:

1. ai_session `get_direct_response()`
for basic one shot requests, without configurability from the UI.
2. ai_agent `generate_single_response()`
for one shot requests, but with configurability through the usage of an
agent and thus with support of agent related features (rag, topics, ...).
Requests can be made from the frontend using the `/ai/generate_response`
route (with an `interface_key` used to get the right agent)
3. ai_composer `action_launch_ai_chat()`
for multi-turns interactions with the llm through a discuss channel.
Sessions can be initialized from the frontend using the `launchAiChat`
command.

Task-5014794