Main purposes

 * cover various use cases of tracking in addons. Several addons are doing
   manual calls to tracking API: '_mail_track' (generating tracking values),
   '_message_track' (generating valu and a tracking message) or calling
   'message_post' or '_message_log' with tracking values manually generated.
   Logging on a parent model is also a frequen need (e.g. move line change on
   move, esg factor line changes on factor, ...). Those should be covered by
   tests to assess the behavior.
 * update tracking API to remove low-level data manipulation and use simpler
   methods. Addons should not have to manipulate tracking values in any
   form.
 * locate tracking code being currently both generic for BaseModel and specific
   to mail.thread in a middle-ground mixin.

Specifications

Test various use case of tracking, notably when doing manual calls to
_message_track (which generates a tracking message), _mail_track
(which generates tracking values, to be included in a message_post)
or logging a message using either manually crafted tracking values or
a rendered body looking like tracking values.

Update docstring and arguments of tracking API. Add type annotations to
ease understanding of the various structures used in code.

Add a 'mail.track.mixin' mixin that allows to generate tracking values
without depending on 'mail.thread'. It also allows to remove part of the
code that was on BaseModel just for models not inheriting from 'mail.thread'.
Thread now mainly adds the posting capabilities based on tracking.

Update tracking API. Introduce '_track_add' when adding a manual tracking
on some values. Introduce '_track_record' when sending the tracking values
on another model (e.g. a parent for logging purpose).

Fix various crashing code bits discovered when adding tracking tests.
Note that most are going to be backported, hence may disappear from
this PR at merge time. Youpie.

Task-5935695 ([mail, various] Cleanup and test tracking usage)
Prepares Task-3645865 ([mail] In-body tracking)

Co-Authored-By: Prakash Prajapati <ppr@odoo.com>

- Unify API of AI methods: including `_get_direct_response`, `_generate_next_response`, and `_generate_single_response` to accept and return parts. Parts represent a list of dicts where each dict has a type such as 'text' or 'inline_data' and a content dict.

- By returning structured AIMessageParts, the system can now support images alongside text.

- Allow image generation using AI from Media Dialog
  
  - Introduce a tool to allow image generation using Gemini Nano Banana which is the state of the art model for image generation in terms of quality, speed and prompt adherence.

  - Introduce logic inside `ai.attachment.vacuum` to remove unused AI generated images to avoid bloating the DB with large files.

  - Duplicate some code from `ir.binary` into `image_tools` to be able to retrieve attachments from paths that have one of the forms:
    - `/web/image/....` for attachments.
    - `/<module_name>/static/...` for files from addons, for example
    /ai/static/description/icon.png

  - Introduce messages quick action buttons to perform the same save logic of the `MediaDialog` and `CustomMediaDialog` by passing the save method from the media dialog to the `discuss_channel`.

- Fix the following bugs:
  - After https://github.com/odoo/enterprise/commit/2acc1178663d3607e96b64c17ea54f1f5c2e86f3, users have the ability to define prompts for ai.prompt.button records instead of using the name field as the prompt. However, the VoiceTranscription  component wasn't updated to use the new prompt field.

  - The _render_prompt method should return the 'name' of the 'ai.prompt.button' if no 'prompt' is defined or no rendering_record is passed to the method. However, this check didn't take into account that 'prompt' may contain empty HTML, for example `Markup(<p></p>)`.

  - Accessing render_model field on 'ai.prompt.button' records raises AccessError for non-admin users.

  - An error would occur if a public user (or portal) tried to chat with the AI using the live chat.

  - The order of prompt buttons in the discuss channel/transcription component was arbitrary. Now, they are sorted based on their sequence.

  - The composer retrieved by the TranscriptionComponent doesn't take the model of the current record into consideration.

  - Composers should be retrieved based on the interface key and record_model but get_direct_response retrieved composers based on interface key only. While not a bug because the only usage of the endpoint (website_seo_ai composer) will always be opened from the SEO component on the website, the retrieval of composers should be consistent everywhere.

- Misc

  - Move some utils from the `ai_fields` module into the `ai` module. The logic defined in `tools.py` in `ai_fields` is now used in the `ai` module. So, the logic is moved into the `ai` module as it is the base for other ai related modules. The code is moved into 'ai_fields_tools.py'.

  - Previously, it was only possible to generate text using AI and AI actions such as 'Log as Note' and 'Send Message' only took text into account. Given that the AI now is capable of generating attachments i.e. images, the actions are updated to take the attachments into account.

task-5153846