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)
Since this seems to be repeated a few billion times, maybe there should be a pattern/registry to execute a method against a link/button? Hell, maybe wherever the buttons live could just call `$target.data('action')` on `EditorBarContent`?