1/ Write a form view with a o2m field that has its own inline tree view
(no other view exist in db for the target model)
2/ Open that view in a mobile environment
3/ Instead of having a list view, you get a kanban view. No luck for
you, since the default kanban generated by `models.py` is an empty one,
your records are *invisible* \o/

From what I can tell, the previous condition made no sense:
```
if (there is a list view and a kanban view)  <-- this seems absurd
  then (use the list mode)
elif (there is no list view but a kanban view)
 then (use the kanban mode)
else (use both modes)
```

The first condition seems absurd: it *actively* ignores a kanban view
if there is one. Even better, the list view whose existence it checks
is never there: it checks for a `tree` when it should be checking for a
`list`. In short, the first condition was *never* met, and you ended up
either with exclusive kanban mode or with both modes - even if you had
no existing kanban view for the target model...

This commit moves the normalization of `tree` into `list` before
attempting to process the x2many field's subviews. It clarify the usage
of `tree` vs `list` (cf. only use `list`) which  prevents weird edge
cases like described above.

closes odoo/odoo#36237

Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Co-authored-by: Adrien Dieudonné <adr@odoo.com>
Co-authored-by: Pierre Paridans <app@odoo.com>

The tests in the file `relational_fields_mobile_tests.js` - which is
part of the mobile test suite - are actually not specific to mobile.

This commit merges those tests asserts into the tests already present in
the regular test suite. It ensures that all the existing asserts remains
and the actual coverage stays the same.

When we open any x2m record (in a FormViewDialog), there is a "Remove"
button to delete/unlink the opened record from parent.

This button is placed besides "Discard" button and it creates little
confusion in some cases. For example, in list view, there's already a
bin / 'x' icon depending on the field type using which people are used
to delete/unlink the record. And when they open a record, they might
accidentally click "Remove" button instead of "Discard".

To avoid this, now we won't show "Remove" button when we open record from
x2many list view. However, we have to keep this button in case x2many of
kanban as there's no other way to remove the record.

task-1886913

closes odoo/odoo#34333

Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>

Part of task 1896658

Co-authored-by: Aaron Bohy <aab@odoo.com>
Co-authored-by: Christophe Matthieu <chm@odoo.com>
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Co-authored-by: David Monjoie <dmo@odoo.com>
Co-authored-by: Martin Geubelle <mge@odoo.com>
Co-authored-by: svs-odoo <svs@odoo.com>
Co-authored-by: Vincent Schippefilt <vsc@odoo.com>

This rev. introduces robust helpers to use in the JS tests suite to
interact with DOM and components, and starts using them (almost)
everywhere.

All the helpers are exposed though testUtils.js.

There are 2 kinds of helpers:

1. Assertions
-------------
 * assert.containsNone, containsN, containsOnce check that the DOM
   (or a specific part of the DOM) contains a `selector`. It
   generates a correct error message automatically.
    ex: assert.strictEqual(form.$('.o_form_editable'), 1, "msg");
        -> assert.containsOnce(form, '.o_form_editable');
 * assert.isVisible, isNotVisible check that the DOM has an element
   visible or not. They also check that the element is actually in
   the DOM (before most tests didn't verify this).
 * assert.hasClass, doesNotHaveClass, hasAttrVAlue, check specific
   properties of a DOM element, and also validate that it is
   applied on a single existing DOM element (before most tests
   didn't verify this).
    ex: assert.notOk(form.$('button').hasClass('btn-primary'));
       -> assert.doesNotHaveClass(form.$('button'), 'btn-primary');

2. Utilities
------------
The goal of the utilities is to centralize the definition of many
standard components and interactions, ensuring that when we
refactor the JS framework, we do not need to change all the tests.

Existing mock utilities (addMockEnvironment, intercept, path,
patchDate, unpatch and fieldsViewGet) are moved to
'testUtils.mock.*'.
Existing DOM utilities are moved to 'testUtils.dom.*'.
New dom utilities are created for opendDatePicker, click,
clickFirst and clickLast. Helper `click` verifies that there is
exactly 1 element visible in the DOM you click on, `clickFirst`
and `clickLast` verify that there are more than one element on the
DOM.
 ex: form.$('button').click();
     -> testUtils.dom.click(form.$('button'));

New Form utilities: (testUtils.form.*)
 clickEdit, clickSave, clickCreate, clickDiscard, all clicks on
 the control panel buttons of the form.
 `reload` reloads the form data.

New modal, graph, kanban and pivot utils (testUtils.pivot.*,
testUtils.kanban.*, etc.).

New fields utils: (testUtils.fields.*)
 * editInput, editSelect: allow to change the value of a field,
   using a selector to identify it. They validate that the input
   exists and trigger the change event automatically.
 * editAndTrigger: allow to modify a field and trigger specific
   events after the value change
 * many2one (testUtils.fields.many2one.*)
   clickOpenDropdown, clickHighlightedItem, clickItem,
   searchAndClickItem: use a field name instead of a selector and
   do all the complex mechanism to open, filter and highlight
   many2one fields.

Joint work with aab, dam, ged, mge, svs and vsc.

This rev. allows to navigate, in mobile, through records in form
views by swiping.

We also moved mobile-specific tests involving a form view to the
mobile test suite, since those tests became async because of the
lazy loading of the swipe lib (in the mobile suite, that lib is
already loaded).

Related to task #34727

Co-authored-by: Mohammed Shekha <msh@openerp.com>