### [FIX] core: fix _RelationalMulti.convert_to_cache()

Since e0297bdac4eac165a79680de3b1139c2f554d5f5, we have tried to manage sibling dependencies in onchange, but we still have a bug: We already have a record N with a record R1 inside its one2many, when we create a new line R2, during the first onchange() on the one2many comodel, the cache of the N.one2many correctly contains R1 and the current new record R2. But at the onchange on a second line R3, N.one2many will only contain R2 + R3 and R1 won't be in it.

This happens because of the _RelationalMulti.convert_to_cache() uses the 'validate' attribute as a way to know if we need to avoid using the default value for new record without origin (see test_40_new_defaults).

Example of the stack:

From onchange: `record._update_cache(changed_values)`
From _update_to_cache, validate=True, field=Many2one, value=dict: `value = field.convert_to_cache(value, self, v
alidate)`
From convert_to_cache: `id_ = comodel.new(value, origin=origin).id`
From new: `record._update_cache(values, validate=False)`
From _update_to_cache, validate=False, field=move_line_ids, value=commands: `value = field.convert_to_cache(value, self, validate)`
From convert_to_cache: `ids = OrderedSet(record[self.name]._ids if validate else ())`

Instead check if it is a new record without origin to know if we need to bypass the default value or take the real/origin values from the cache and apply the commands to it.

### [FIX] base_automation: fix usage of convert_to_cache()

In the previous commit, we changed the behavior of convert_to_cache() for X2many fields when validate=False. The base_automation was relying on this to compare old and new values of X2many because the old values were in read format and the new values were in record format.

Instead of relying on read(), use the record format for old values and compare the record values. There are some minor changes:
- We now fetch less data because the read() fetch display_name of many2one and if vals is empty will actually fetch all fields for no reason.
- The order of X2many generated by command values doesn't matter anymore, but it shouldn't anyway, because we only want to trigger the base automation when the set of records changes. (Add a test ?)

### [FIX] tests: better simulate M2M in server side Form

Since e4b66668e0ff3d5444ef7fc7b79e6226c513e2c0, the webclient sends LINK and UNLINK commands for many2many values, but the Form test class only used SET commands. Try to mimic the web client more closely.

Forward-Port-Of: odoo/odoo#168735

Steps to reproduce
==================

Example A)

- Install project
- In the settings, enable subtasks
- Open any project
- Open any task
- Switch to the "Sub-Tasks" notebook tab
- Add a new line with a very long name
- Save

=> The list overflows to the right and does not allow to scroll

Example B)

- Install Expenses
- Go to Expense Report
- Open any record
- Enable every optional column
- Reduce the window width

=> Same issue

Cause of the issue
==================

Without a custom widget, the classes on a one2many field are `o_field_widget `o_field_one2many`.

With a custom widget, the classes are for example
`o_field_widget o_field_subtasks_one2many`.

This means that this [css] snippet is not applied. An attempt has been made to pass those classes in [additionalClasses], but it's missing in the examples used to reproduce this issue.

In the example B, the list is wider than the allowed space, because the minimum width for a column is [92px] and if we sum them all, it is more than the total space.

Those issues have become more apparent since a [fix] for Safari. The allowed width was computed with a fixed table layout, which means in most cases, it was a bit less.

We can see though that even before the [fix] for Safari, there were still issues, for example in the example B.

Solution
========

We add back the css removed from the [additionalClasses] fix.
It was removed initially since `:has` was not supported in Firefox.
It is now supported since 2023-12-19.
Still, if someone has an old version, it will not fix the issue.
For that, we still add the classes to the two reported widgets.

---

[css]: https://github.com/odoo/odoo/blob/6abd479dcae0e206155d8d7171b62e384fa61740/addons/web/static/src/views/form/form_controller.scss#L710-L718
[additionalClasses]: https://github.com/odoo/odoo/pull/121182
[92px]: https://github.com/odoo/odoo/blob/ae5de53c3f4009d23ec556be4abb9eefd111f9b7/addons/web/static/src/views/list/list_renderer.js#L395
[fix]: https://github.com/odoo/odoo/commit/ae5de53c3f4009d23ec556be4abb9eefd111f9b7

opw-4010760
opw-4028675

Forward-Port-Of: odoo/odoo#172926