Goal abstract
===================
* Simplify the way to define modifiers (*required*, *readonly*, *invisible*, *column_invisible*);
* Use python expression in view to define modifiers;
* Clean python field and remove some keys;
* More accurate validation of xml views.

Operation before change
===================
Problem before the changes: it was difficult to be able to create a view
using modifiers. There were different ways to describe these modifiers
and each way interacted with the others. Here are the different ways
they existed to describe a modifier:
* the *required*, *readonly* and *invisible* attributes could have
values of *True*, *False*, 1, 0 or a python expression to use the
context.
(eg: `<page invisible="not context.get('show_me')"/>` )
* the *attrs* attribute define a dict. The key of this dict was
*required*, *readonly* and *invisible* and the values are the domain or
a string representing a domain to be evaluate as python expression.
This python expressions was evaluated by the javascript with view fields
and other contextual values such as: context, uid, parent, active_id,
active_ids, active_model, allowed_company_ids, current_company_id.
(eg: `<field name="total" attrs="{'invisible': [('name', '=', 'red')], 'required': &quot;[('tag_id', 'in', uid)]&quot;}"/>`)
* the *states* attribute in the view was a comma separated list of the
state. This list was combined with the *invisible* attribute.
(eg: `<page states="draft,done">`)
* the key on python field is used as default value (including *invisible*).
(eg: `fields.Boolean(invisible=True)`)
* the *states* key on python field was dictionary with state as
key and list of tuple. This structure was combined with *readonly* view
attribute.
(eg: `fields.Boolean(readonly=True, states={'draft': [('readonly', False)], 'done': [('readonly', False)]})`)

After combining this different ways (with a post-processing in python then an
evaluation in JavaScript), the resulting domains of the different attributes
*required*, *readonly* and *invisible* are evaluated (in JavaScript) with the
values of the fields available in the view. The *invisible* attributes is splitted
into two use: *invisible* and *column_invisible*.

Goal
====
Simplify the way to define modifiers (*required*, *readonly*, *invisible*,
*column_invisible*). 
Users will be able to define modifiers in the view using python expressions.
These will be evaluated using the values of the fields available in the view,
as well as various contextual values (*context*, *uid*, *parent*, *active_id*,
*active_ids*, *active_model*, *allowed_company_ids*, *current_company_id*).
This evaluation will be done by JavaScript (py.js library). Its expressions
don't need to be evaluated by python. Unlike before, views no longer
have post-processing to modify them.

Example
=======

```xml
    <field name="field_a"
              readonly="not context.get('show_a')"
              attrs="{'readonly': [('field_b', '!=', False), ('field_c', '=', parent.c)]}"/>
    <field name="field_b"
              states="draft"/>
```
will be replaced by
```xml
    <field name="field_a"
              readonly="not context.get('show_a') or field_b and field_c == parent.c"/>
    <field name="field_b"
              invisible="state != 'draft'"/>
```

Some inherited views will be modified differently in order to maintain
the previous behavior:

```xml
    <field name="field_a"
              readonly="not context.get('show_a')"
              attrs="{'invisible': [('field_b', '!=', False)]}">
```
```xml
    <field name="field_a" position="attributes">
        <attribute name="attrs">{'readonly': [('field_c', '=', False)], 'invisible': [('field_d', '!=', '3')]}<attribute>
    </field>
```
will be replaced by
```xml
    <field name="field_a"
              readonly="not context.get('show_a')"
              invisible="field_b">
```
```xml
    <field name="field_a" position="attributes">
        <attribute name="readonly" add="(not field_c)" separator=" or "/>
        <attribute name="invisible">field_d != 3<attribute>
    </field>
```

Validation
========
A stricter control is made on the level of the attributes (modifiers and domain)
The domains, and python expressions are parsed and every name of dynamic values are extracted. The field names used in the expressions must be present in the view.
The use of the previous attributes *attr* and *states* triggers an
error (these no longer exist after the application of the migration script)

https://github.com/odoo/odoo/pull/104741
https://github.com/odoo/upgrade/pull/4884
https://github.com/odoo/documentation/pull/3523

task-2495504