This commit introduce a full redesign of all JS views.  We started
basically from scratch.  The goal was to unify all the various views
under a common framework, to make them testable, to make then usable in
different conditions (in studio, or in the frontend), and to make our
lives easier.

Some important points are:
- we introduced new coding guidelines (camelCase, 80 chars width, ...)
- we have a brand new testing framework (still QUnit based)
- kanban view moved to the web addon
- calendar view (formerly web_calender) moved to web as well
- the tree view was removed
- all new code should be documented

We hope that this code is the start of a new era for the Odoo web
client, we want to have a high quality codebase, well documented, well
tested, well designed.

Work done by the framework team: mostly aab, ged, chm, dmo, qsm

When the user searches for date (or a datetime) in the search bar, the
suggested date can become completely wrong. For example, in the French
localization where the date format is DD/MM/YYYY, the system will search
for the date MM/DD/YYYY. This is even worse when the date is not fully
written: DD/MM could be converted to MM/DD/0000, which doesn't make any
sense. This is related to the moment issue
https://github.com/moment/moment/issues/1407.

The fix is to make sure that the input date has a correct format thanks
to `parse_value`. The latter converts the date into a fixed format.

Fixes #11876
opw-676604

Avoid duplicating web addon in enterprise by extracting a common basis.
Enterprise features stay in enterprise, but use that common basis.

Mainly:
 - JS refactoring and linting
 - Conversion of .sass into .less split into multiple files
 - Templates cleaning and DOM simplification
 - Re-generation of web.pot, and update of .po files

Introduction of 'data_manager' service which handles meta-data related to
actions and views (fields_views, fields and filters). Ideally, all RPCs to
get that kind of information should go through data_manager, as it holds an
internal cache.

Hopefully "group by" is already translated somewhere else so does not break trads

Enhance current widget="monetary" client-side feature and
convert it to a first-class type of field, allowing proper
server-side behavior.

- fields: add field.Monetary, similar to fields.Float but
  supporting a `currency_field` attribute instead of the
  decimal_precision attribute.
  `currency_field` indicates the field holding the
  related currency on the same record.
  The symbol of that currency is used when displaying
  the field, and the rounding of the currency is applied
  instead of the usual decimal precision.
- avoids application of a second decimal precision rounding,
  as was the case when the model field was a `fields.float`.
- removes the need for adding explicit boilerplate to each
  view containing a monetary field, i.e.:
    widget="monetary" options="{'currency_field': 'currency_id'}"
- res.currency: add new field decimal_places needed to round
  value at the correct decimal places
- web: cache all currencies, rounding and symbols at
  webclient startup to speedup monetary fields
- new widget monetary for list view + adapt widget monetary
  on form view

Limitations:
- if the currency_field is a related field, the server-side
  application of currency rounding will only work when the
  record already exists, not during creation (to be fixed)
- this field is only supported in the new API

The module system needs to know the dependencies of a given module
before executing the function.  This is why the dependencies were
defined once in an array, and then were described one more times in the
call to require.

But a trick can simplify this: the boot function can parse the string
representation of the module and extract the calls to require from it.
It is more work for the processor, but it leads to simpler module
definitions.