This commit improves the JS code of the mail module,
which comes maily from the new coding guidelines
and the addition of "JS services".

JS services are important objects that do not fit
well in the component tree, such as chat_manager
or ajax.

The benefits of JS services are improved readability
of the code, reduced coupling, and more testable
modules. In particular, discuss was hard to

Summary of the changes:

- ClientAction has been renamed into Discuss
- Clear instantiation of chatManager
- New coding guidelines in most mail modules
- JS Services can interact with each other
- Chat Manager and Window Manager are services
- Window Manager renamed to Chat Window Manager
- bus.bus is now encapsulated in Bus Service (a service)
- The test infrastructure has been tweaked with JS Services
- Chat Mixin has been removed

A future improvement would be to translate some 'trigger' into 'trigger_up'.

This rev. is the first part (out of 3) of the refactoring of the
ActionManager and ViewManager layer of the webclient.

The main changes are:
  - there is no ViewManager anymore, its work is now handled by the
    ActionManager itself, but isolated in a specific file ; this
    eases a lot of things, as the breadcrumbs handling for example.
  - the ActionManager code is converted to the new coding principles
    and guidelines ; mainly, children widgets communicate with it by
    triggering events up, and not by function calls anymore.
  - the ActionManager layer is now testable, and a lot of tests have
    already been written.
  - the code in other addons has been adapted consequently.

What's coming next:
  - introduce the 'AbstractAction' Widget, and make client actions
    and view controllers inherit from it ; this widget will
    implement a common API that could be used uniformly by the
    ActionManager (e.g. restore(), canBeLeft(), renderButtons(),
    getTitle()...).
  - move the ControlPanel handling from the ActionManager to the
    AbstractAction.

Oversight of previous forward-port

Before this rev., the default filters were ignored in Discuss. The
SearchView was instantiated and correctly retrieved the default
filters. However, a first manual 'do_search' needs to be done by
the client action for the search view to provide the domain, and
for Discuss to correctly filter the messages.

Steps to reproduce the issue:
  - In Discuss (e.g. in Inbox), add to Favorites a given search,
    and tick 'Use by default'
  - Leave Discuss, and then go back: the default filter correctly
    appears in the search view, but the messages aren't filtered.