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

A refactoring of the js views is in progress.  Those new views are used
in web studio, and this change is part of it. This is necessary to allow
web studio to correctly fetch data from the server when rendering a
preview.  Note: this is necessary for special widgets (status bar,
selection, radio widgets)

Sometimes, we need better control on the cache.  For example, if a view or an
action has been changed, it is required to make sure that the correct
data is loaded.

The action object, and in particular its context, is modified by the Action
Manager and by some views (e.g. sales_team_dashboard Kanban). So, as the action
is stored in cache, the same object was returned each time the action was
requested, and previous modifications of its context still applied.

This produced a bug with the sales_team_dashboard when following those steps:
  - click on the link to today's activities, it opens an action with
    'search_default_today' in the context,
  - come back to the dashboard
  - click on the link to this week's activities, it opens an action with
    'search_default_this_week' in the context, but the formerly added key
    'search_default_today' is still there as well, so the domain is wrong.

Before this rev., if an error occured during an RPC handled by the
data_manager, the RPC result was stored in cache anyway, and there was thus no
other way than refreshing the page to get correct result for that RPC.

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.