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

Steps to reproduce the bug:
1.Create a new company
2.Set a user in this company
3.Go to Helpdesk > All tickets > Create

It raised a traceback because stage_id was not defined

opw:710084

Make sure the widget won't crash when no `terminology` option
is passed.

Also for the translation extraction system to work, each literal
term needs to be enclosed in its own _t() call:

  // No
  var trans = _t(term || "Default term");

  // Yes
  var trans = _t(term) || _t("Default term");

The _t() function supports `undefined` arguments so the second
form is equivalent to the first form at runtime, but supports
proper term extraction.

Finally, simplified the implementation a little bit,
requiring `hover_true` and `hover_false` "action descriptions"
to be provided explicity in custom terminologies.
Previously we tried to reuse the values from `string_true` and
`string_false`, but they describe a state rather than an action,
so they are hardly ideal.

(1) The priority widget is based on a selection field.
So, this priority widget must support string values.
Before this commit, the widget worked correctly with numeric values.
For example: '0', '1', '2', '3' was converted to 0, 1, 2, 3.
But sometimes, we have non-numerical values.
For example: 'Normal', 'Low', 'High', 'Very High'.
In this case, we can not compare the elements to each other according to their values.
If you select 'High', we don't know if the star of the value 'Low' must be filled.

To fix this, we base the comparison on the indexes of the table of possible values.
For example:
[('A', 'A'), ('B', 'B'), ('C', 'C'), ('D', 'D')]
Now, if you select D, we know that A (with index 0)  is smaller than D (with index 3).

This could be a behavioral change if you had [('1', '1'), ('0', '0'), ('2', '2')]

(2) When the selection field had no value, the 'o_form_field_empty' class was added.
In this case, the stars must be displayed without being filled.

This will be used on a sale_coupon_program