Front-end/back-end integration

Purpose of this task is to lower the differences between back-end and front-end. It is done by
embedding a navbar on both sides. The edit bar has been merged in the front-end navbar.

* The top-menu of the backend is now rendered server-side. This allows to use the same template
in the front-end and to avoid a flickering on different end switching. Backend navbar is appended
totally outside the webclient table mess in order to be correctly responsive. The downside is that
the announcement bar is appended in a table before the navbar, because its css must be backward-
compatible.
* Some widgets of the webclient set in chrome.js does not render thei dom but use already-rendered
one (webclient, menu).
* front/backend use different methods to handle the behavior of the navbar on the resize.
* Use of fontawesome icons on the navbar (mail, timezone, chat)
* Methods building the menu_data were moved on the ir.ui.menu models. The menu_data dict is available
in the qweb rendering context when the user has group_user
* Widgets of website have been refactored. Website.editorBar is splitted in editorbar, ace, editorbar-
content, editorbarCustomize. It is done because, in the future, we may want to embed some widgets in the backend (probably customize and help).

TODO: addons/web/tests/test_menu.py is commented-out
TODO: fix the appearance of edit button according to the user's right (probably broken since
the asset merge)
TODO: js_hide_on_translate should be removed
TODO: rename widgets with more accurate names (for instance, EditorBarContent => Content)
yes, the hash is used internally by AceViewEditor. But in this case, i totally removed the start method from the website.ace widget, because it was not even used (i don't append the widget, i bind an event on the existing dom to the launchAce method of the widget). But it is bad practice (and i should feel bad).