This commit adapts tests following recent changes on the helpers.
The main change is that addMockEnvironment (and all functions using
it) are now async, as they need to wait for services to be started.

Before this rev., the 'fieldChanged' event was triggered each time
the user selected a value (a day, an hour, a minute or a second) in
the datepicker. This means that if there was an onchange on the
field, a lot of RPCs could have been done when a user set a
datetime. In addition, in a list view with multi edition, the user
was asked to save the changes at each step of the datetime
selection, making the feature unusable.

Task 2068280

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>

The option `showSearchInput`, which is used on the model field selector to display a search
input that filters the displayed fields, is not set by default.

This includes the model field selector instantiated in the `domain` field widget.

closes odoo/odoo#29986

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.

The datepicker lib has been updated to tempus dominus (BS4)
recently, but our code hasn't been adapted correctly to the
requirements of the new version of the lib. As a consequence,
the datepicker didn't close itself when the input was focused
out anymore.

This required a slight change in the DomainSelector widget as it
produced a crash when a focused datepicker widget is removed from
the DOM (before the datepicker is destroyed), e.g. by a call to
html() on one of its parent.

Task 1878254

This option is used to set a default domain value when creating a new node
(instead of [['id', '=', 1]]).

A domain could contain the key `parent` (in an embedded subview), like:

    domain="[('display_name', '=', parent.display_name)]")

This is currently not handled by the DomainSelector.

This will probably be handled in a future version but for this stable version,
this case that triggered an error is now catched and an error message is
displayed in the widget.

This was causing a traceback when opening a domain with `parent` in the edition
of a subview with Studio.

Since the new views, the field parsing for m2o returns an object with
id and display_name. If the given value to parse is a string, it is
supposed that this is an ID. This was breaking the domain selector
widget which should allow strings as name-strings of m2o values.

Before this commit, and since the combination of new views + datepicker
library update, the datepicker opened at the top left of the window
when using it in a domain selector. It also could not be used at all.

This was because the current scenario occured:
1) Click on the datepicker
2) The datepicker triggers that it has changed on opening
3) The whole domain selector is rerendered
4) The datepicker computes where it should open... on basis of the
   old destroyed domain selector

As the main cause of the problem here was the (2), this commit changes
the datepicker odoo widget to only notifies that it has changed when it
has really changed.