### [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#173066
Forward-Port-Of: odoo/odoo#168735