The old tree views don't really exist anymore, this odd pseudo-flag to
dispatch between "list" and "tree" tree views has no reason to remain.

Task 1937686

closes odoo/odoo#31243

Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>

with the new views, we removed the many2many_kanban widget on many2manys, since it is the default behaviour anyway, but we also removed it for a few one2manys.  And this is a mistake, some one2manys have to behave like many2manys.

(PR #17190)

The remaining widgets were KanbanRecord and the two quick create
widgets. Now, all kanban files have been converted and refactored.

* hr_attendance, hr_gamification, hr_recruitment, mass_mailing,
  project, sales_team

Before this commit, the kanban column did not know about the model
name which make customization impossible without a getParent. Kanban
records were supposed to know about this thanks to the options
parameter but this was broken. Now the model name is automatically
initialized from the given state.

Adapt all extensions which relied on this.

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

The kanban view has been split in various files, and js modules
using them need to correctly import the classes.

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.

bzr revid: mat@openerp.com-20130416124558-p40tkw8mgr4e7v04

bzr revid: mat@openerp.com-20130412152150-8679huigt6cfmool