- Store previous arch to be able to reset it (soft reset)
- Add the possibility to reset from file if possible (hard reset)
- Adapt frontend reset page to these new fields
- `arch_fs` hack to check if view was modified got moved to new field
  `arch_updated` as we now need to keep track of the `arch_fs` to reset a
  broken view.

Closes #32009 (task-1943001)

This commit also:
- adds the possibility to reset a view arch in its form view, including a diff
  viewer (github like).
- adds string helper on those arch fields, as they are not documented, it is not
  always obvious to get the purpose of each fields.
- adapts the font-size and headings to fit Odoo style on the error 500 page.
  The error page does not use Odoo's assets, just bootstrap.css (the cursor
  might be broken on the error 500 page so we can't use Odoo assets).
- raise the caller on unexisting t-call during QWeb rendering.
- adapts reset view code to single view as the code still had remains of its
  initial release (Odoo 9.0). Handling multiple views has no sense anymore.

Purpose
The assignation method should always give the new conversation to the operator who 
has the less active conversation. 
If two operators have the same amount of active conversation, it should chose one of 
them randomly.
We also want the visitor to get the same operator (if available) from its last visit. 

Specifications
The method 'get_mail_channel' on the 'im_livechat.channel' model used a simple random.choice in 
the available users to select the operator.
It was improved to select the operator that has the lowest number of open livechat sessions. If multiple 
operators share the same number (lowest) of open livechat sessions, it selects randomly between those.

For the visitor to get the same operator as during its last visit, we save that information in a cookie (1 week lifetime), and give this optional parameter to the server when asking for the livechat session.

To make the code clearer, some methods were reorganize and convert from `api.model` to `api.multi` (ensure_one) to be more API-compliant.

Task-1919871

Rationale:

Most onchange includes business logic (ex: changing a partner on an
invoice sets the fiscal position, and the payment terms). But the
business logic should not be exclusive to the user interface. Thus,
most of these onchanges should actually be compute with store=True
and readonly=False.

Compute fields are usually orthogonal between each others, thus simpler
to implement and inherits. Example: on an invoice, it's easy to
implement _compute_fiscal_position (it's a related
partner_id.fiscal_position_id), but very complex to implement
_onchange_partner_id (it has impact on lots of different concepts
depending on installed modules: fiscal positions, payment terms,
address, ...). By splitting this big onchange into smaller compute,
it should simplify the code and inheritability.

USE CASE 1:

If onchanges are replaced by compute fields, the code to create an
invoice is simplified as you can let the business logic do its job:

    self.env['account.invoice'].create({
        'partner_id': 1
        'line_ids': [(0,0,{
            'product_id': 1
        })
    )}

-> the compute fields will compute the right fiscal position, taxes,
customer address, etc. It's not the role of the sale order to implement
this logic anymore.

This should simplify tests too as you cover more business logic code
with less data to provide.

USE CASE 2:

Let's say the module l10n_mx want to add a TAXCODE field on an invoice,
there is two way to do it:

    @api.onchange['partner_id')
    def _change_partner_id(self):
        super()
        self.taxcode = self.partner_id.taxcode

or, the new approach:

    @api.depends('partner_id')
    def _compute_taxcode(self):
        self.taxcode = self.partner_id.taxcode

The onchange approach creates a big issue: you will have to create modules
like l10n_mx_sale and l10n_mx_subsription. Because, when these modules create
an invoice, they will have to call the code to set the taxcode.

With the new approach, there is nothing to do. Every module who create
an invoice will have the new business logic applied automatically: no
need to create glue modules.



--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr