* web, survey

This commit takes advantage of the other commits of this PR to enable
lazy loading for most frontend javascript:

1) Extract the minimum part of the assets common:
- promises library and polyfill
- boot.js

2) Create "assets_common_lazy" which is "assets_common" - "minimum"

3) Include the "minimum" assets in frontend layouts using "defer"
   loading and "assets_common_lazy" using "lazy" loading

4) Create a script to do the actual lazy loading in a "minimum" frontend
   assets

5) Lazy load the current frontend / website editor assets

Part of https://github.com/odoo/odoo/pull/32181
task-1961045

* website

Part of https://github.com/odoo/odoo/pull/31147
task-1925327

Part of task 1896658

Co-authored-by: Aaron Bohy <aab@odoo.com>
Co-authored-by: Christophe Matthieu <chm@odoo.com>
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Co-authored-by: David Monjoie <dmo@odoo.com>
Co-authored-by: Martin Geubelle <mge@odoo.com>
Co-authored-by: svs-odoo <svs@odoo.com>
Co-authored-by: Vincent Schippefilt <vsc@odoo.com>

Move the 'Show Logo', 'Show Sign In' and 'Fixed Top Menu' options from
the customize menu to the customize theme dialog using new features
introduced with https://github.com/odoo/odoo/pull/29624

The customize menu divider is also only added if there are toggable
options in there (which is not the case anymore for all pages since
this commit).

PR https://github.com/odoo/odoo/pull/29624
task-1904244

* web_editor

Following the new editor's merge at https://github.com/odoo/odoo/pull/29775,
the editor dialog and the switches crashed on their use in website.
This is because the merge split some xml files without adapting xml
dependencies... this commit only takes care of code which depended on
'/web_editor/static/src/xml/editor.xml'.

closes odoo/odoo#30408

* Creating a new structure by transforming all the plugins in the
  library using the odoo inheritance system. Plugins are easier to
  implement with the AbstractPlugin to add Odoo behaviors.

* From now on, the methods of the library (in this case Summernote) can
  no longer be called by other modules or files. Only the wysiwyg
  widgets can access it, to simplify the updating process. The wysiwyg
  object serves as an interface.

* Depending on the options the snippets will be loaded or not, the
  editor will be in an iframe or not... all of this is transparent from
  the outside.

* Regarding iframes, all controllers related to editing have been
  removed: the new API no longer needs them. This speeds up loading,
  eases testing and removes complexity for the same
  features.

PUBLIC FEATURES

There are several public methods on the Wysiwyg class:
* Wysiwyg.prepare (WidgetParent): returns a deferred resolved when the
  library (xml, lazy, assets...) is loaded.
* Wysiwyg.getRange (DOM): returns the range (selection in the dom)
* Wysiwyg.setRange (startNode, startOffset, endNode, endOffset): creates
  a range (selection in the dom)
* Wysiwyg.setRangeFromNode (DOM, options) that creates a range from an
  element (option available to select all, start or end)

A jQuery selector was added: :o_editable, which indicates whether the
current element is editable. That is, if it is contained in a tag with
the attribute 'contentEditable = "true"' or in a tag with the class
o_editable.
Several methods are also present:
* focusIn: makes a focus and places the cursor at the beginning of the
  element
* focusInEnd: makes a focus and places the cursor at the end of the
  element
* selectContent: makes a focus and selects the content

HTML FIELD

The HTML field can receive different options:
* style-inline: {boolean} transforms a class into an inline style when
  saving and vice versa when reading.
* no-attachment: {boolean} prevents the use of attachments (in media
  dialog)
* cssEdit: {xml_id} to use a template containing the css to loaded in
  an iframe when editing
* cssReadonly: {xml_id} to use a template containing the css to load
  into an iframe when viewing in readonly
* snippets: {xml_id} snippets template (can be used with or without
  cssEdit)
* wrapper: {template} qweb static template (containing a tag:
  id = "wrapper") that will include the content during editing (removed
  on save)

MASS MAILING

A widget was created for mass mailing. There are now two fields:
body_html and body_arch.
body_arch contains the code with the class without conversion into
inline style, useful when editing and one with the inline style that is
visible in readonly mode and sent by email.
Advantage: no spreading errors, able to update css/theme, able to do
more changes when converting to inline style so that a maximum of mail
clients have an impeccable rendering.

Co-authored-by: Antoine Guenet <age@odoo.com>

When opening the customize menu as soon as the page became visible, an
RPC crashed and the toggable options did not appear anymore. This
happened:

1) DOM is ready.
2) The user click on the menu.
3) At the same time, the customize menu is initialized (`attachTo`),
   its event handlers are bound and the async `willStart` method is
   called.
4) The event handler for the user click is called... and crashes as
   requires a variable which would have been set in the `start` method.

The bug did not appear in previous versions as the handler was not using
the standard system and bound the event handler "by hand" in the `start`
method.

Maybe `attachTo` should not bind event handlers before the `willStart`
method is completed; this would be a subject for the master branch. This
commit solves the problem by setting the required variable in the
`willStart` method instead of the `start` method.

closes odoo/odoo#28578

This commit fixes a bug introduced with https://github.com/odoo/odoo/pull/28251:
When opening the ace editor on page load thanks to the #ace-view-editor
URL hash, a JS error occurred preventing the editor to open.

This was due to the way actions were executed on page loading:
- Menu elements are initialized and can handle actions
- On initialization, the ace menu tried to launch the editor
- First, it asked that all widgets are closed (see mentioned PR)
- The website handled that action demand by asking everyone to close
  their widget
- The 'new content' menu tried... and failed as referenced a variable
  which would only have been created in the start method.

Conclusion: before handling actions, all action-capable widgets should
be started. This is what this commit does: when receiving an action
demand, we first wait for the action handler to be fully started. This
implied another change: before, many menus were waiting for the result
of an action to notify that their start method is finished... this
would cause a deadlock in the new system so those were removed, this did
not make much sense anyway (if the result of that starting action has to
be known, a dedicated event/method should handle that).

closes odoo/odoo#28364

- The affix navbar went over the ace editor, preventing to save/close
- The ace editor went always under the new content menu

Now:
- The affix navbar is always under the ace editor
- The ace editor closes when the new content menu opens
- The new content menu closes when the ace editor opens

closes odoo/odoo#28251

* web_editor, website_blog, website_crm_partner_assign, website_links,
  website_livechat, website_mail_channel, website_mass_mailing,
  website_slides

Calling a model's method thanks to an RPC will now always send the
web_editor context automatically, making sure the method gets the
website_id all the time, removing the need to guess the current website
(now the get_current_website method uses the context website_id if any).

Note: other routes already have the website_id via request.env.context
if they correctly set website=True (this commit also adds website=True
for scss files customization routes).