of check_company=True fields.

Suppose two models

class A:

    company_id = fields.M2O() # not required

class B:
    _check_company_auto = True

    company_id = fields.M2O() # not required
    a_id = fields.M20(check_company=True)

and the following code:

a = A.create({'company_id': 1})
b = B.create({'a_id': a.id, 'company_id': False})

The creation of B will fail because of the multi-company checks, which is expected.

Nevertheless, since 0d30cc2bc9b9cc2b805d6c2d0a440f185c648da0, the domain of the field a_id would be:

(company_id and ['|', ('company_id', '=', False), ('company_id', 'in', [company_id])] or []) + ([])

which means that through the interface, if you create a record b following the example above (no company_id on b), the evaluated domain would be empty, allowing to select records of class A, even if they belong to another company. Of course, this would lead to a multi-company error when trying to save the record.

This commit makes sure that the right domain is applied on check_company=True fields, even if the current record has no value in its `company_id` field.

opw-3629374

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

Forward-Port-Of: odoo/odoo#146331

Steps to reproduce the bug (starting from saas-16.4 only!):
- Go to the website app
- Enter edit mode => Bug: the editor toolbar appears for a few ms, then disappears.

This bug occurs since [1], whose original commit was actually merged in 16.0 with [2]. The reason the bug only appears in saas-16.4 and not 16.0 is because of [3].

Commits [1] and [2] change the elements that are considered "tab-able" and thus the elements that can be auto-focused by the `useActiveElement` hook. That hook is actually used when we enter edit mode since [4], as a way to declare the editor as the active element so that keyboard shortcuts work (as indicated by the related commit).

What actually happens thanks to the hook is that once we enter edit mode the "Block" button of the right panel is focused. This is because it is considered to be the first "tab-able" element (with or without [1]/[2]). Then keyboard shortcuts work as expected as the right panel is focused.

However, since [3], the `useActiveElement` hook is called "too soon". Indeed the right panel is not actually inside the "auto-focused" editor container yet**. The result is that what is now "auto-focused" is the editor toolbar***. Before [1], the element in the toolbar that was focused was an invisible one, so no bug appeared. Since [1], we only auto-focus visible elements... so we now focus a visible element in the editor toolbar, making it visible during editor instantiation.

This commit fixes the issue independently of [3] (which is why this targets 16.0: to consolidate the codebases). Actually, the use of the `useActiveElement` hook added by [4] is useless. It was fixing the issue at the time, but the real solution was to do what was done since at [5]. Indeed, the keyboard shortcuts were not working because the backend navbar was still visible (even if outside of the viewport) so it was its keyboard shortcuts that took precedence. Since [5], the use of `useActiveElement` actually has not benefit anymore. The editor is part of the backend UI, the backend UI is still focused after entering edit mode, shortcuts targeting the editor panel are thus working naturally. Removing the use of the `activeElement` hook only has one side effect: the "Block" button of the right panel is not auto-focused anymore... which is not needed.

Notes:

- The `useActiveElement` hook also has another purpose: allowing cycling using tab and shift-tab, it should work naturally as with the backend UI anyway but mainly: tab and shift-tab do not seem to be working with the editor UI anyway.

- Another hint that [4] was not right way to go is that this is the only use of the `useActiveElement` hook in the whole codebase, except for the framework use for dialogs.

- ** That should maybe be solved on its own, although maybe it is not important and risky at best.

- *** The editor toolbar should not even be instantiated that way in the first place since it will be attached to the right panel later... but that is another issue.

[1]: https://github.com/odoo/odoo/commit/c631bf09b927003edc4c2b85e8790e8e2e8c044a
[2]: https://github.com/odoo/odoo/commit/57452ee59c3e33eaa219d8d7b8d82239fd33b722
[3]: https://github.com/odoo/odoo/commit/76d4f9811b756f0e57b0a33dbba534c900c7fe15
[4]: https://github.com/odoo/odoo/commit/b0108e1876a27e83231e176cdca3e2d67d6a2a9c
[5]: https://github.com/odoo/odoo/commit/cdc8d4c889b316664323afad0d848403960150d5

task-3686730

Forward-Port-Of: odoo/odoo#151209