__Before this commit__
The `ai.session` record linked to a `discuss.channel` is not accessible
from the frontend.

This is a problem for the website builder AI because in some cases we
need to know if an AI chat session was launched from the website builder
sidebar. For instance, to implement custom behaviors such as blocking
the website page iframe while the AI is thinking.

As a workaround, we currently check if the channel agent external
identifier corresponds to the website builder AI, however this might be
edited by the user, which would break the flow.

__After this commit__
The inverse field `ai_session_ids` is added to `discuss.channel`. In
practice, there might only be a maximum of one `ai.session` linked to a
channel, but we keep it plural as a convention for `One2many` fields.

Only the `ai.composer` and the `interface_key` linked to the session are
put in the store at the moment, but fields can now be easily added if
needed.

We can now check for the `interface_key` in the frontend to know from
which part of the code an AI session was launched.

Those models have also been added to the Hoot mock server. The
`action_launch_ai_chat` method is added to the `ai.agent` mock model
and returns the session and the composer.

task-5411100

Forward-Port-Of: odoo/enterprise#114472

* = [account_intrastat,approvals, documents_product, helpdesk_sale_timesheet,hr_expense_stripe,l10n_ke_edi_oscu, l10n_ke_edi_oscu_stock,l10n_pe_edi_stock,mrp_plm, pos_pricer, quality_control, sale_subscription]
- Drop all view inheritances targeting the removed product_variant_easy_edit_view
- Remove `Product Variants` menus from Approvals and Quality Control
-added account_avatax  inside the Accounting tab group
- Move pos_pricer Pricer group to after the Short Description group in
  the Sales page remove on_sale_price and pricer_tags_pricelist_id fields from
  the variant form
- Remove product_product_view_list_at_date list view
- Remove mrp_plm ECO button from variant form
- Update sale_subscription variant field to many2many_tags_color_dot widget
- Simplify UI extensions by removing redundant variant-only fields and
  customizations
- Clean obsolete view logic and tests relying on direct variant editing
This aligns product variant handling across modules, and ensures a consistent
user experience.

See Also:
Community PR:https://github.com/odoo/odoo/pull/244185
Upgrade PR:https://github.com/odoo/upgrade/pull/9276
task-5207510

Up until now, by specifying a ttf font file in the use_custom_font system parameter, one could allow the display of different fonts or alphabets in the pdf generation in sign. With this PR we want to explore the possibility of defining multiple fonts, which would allow both for the use of different alphabets in different documents (without always having to go modify the system parameters) and multiple alphabets in the same document, in different text boxes/selection menus.

The way it works is that a variable called sign.use_custom_font needs to be created in the system parameters and populated with a list of ttf files, separated by a ;

For example, if one wants to add the fonts for Arabic and Bengali which are in files named NotoSansArabic-Regular.ttf and NotoSansBengali-Regular.ttf, the value of the newly created system variable should be: NotoSansArabic-Regular;NotoSansBengali-Regular

The code should check all the usual folders for fonts. If a file is not found it is ignored and a warning is logged. At document rendering time, if an appropriate font is not found for a text to be displayed in a Text, TextArea or Selection field then the system defaults to Helvetica (latin alphabet) and most different-alphabet symbols are rendered as black boxes. This is intended.

Task: 4731754