(cherry picked from commit 184744e)

Related to Odoo task : https://www.odoo.com/web#action=333&active_id=1695&cids=1&id=2522564&menu_id=4720&model=project.task&view_type=form

… open

We achieve this by inserting and selecting a zero-width space when
deleting the element.
This is so far limited to unremovable elements but we could potentially
expand this logic to all inlines if we choose to have that behavior. In
that case though we'd have to handle the systematic removal of these
potentially parasitic zero-width spaces, and adapt a lot of tests.

The current method to identify bold text failed when the "bolder"
font-weight was smaller than 500, which happens if the normal
font-weight is set to less than 400. This is the case with Bootstrap's
"lead" class for instance.
Checking if it's bigger than 500 is useful for marking headings as being
bold. However we need to also check if the element's font-weight is
bigger than its parent block - in which case it should be considered
bold.
Using `font-weight: normal` to unbold again fails if the inherited
font-weight is smaller than 400 (eg: text in a ".lead" element inherits
a font-weight of 300 but `font-weight: normal` is the same as
`font-weight: 400` so setting `font-weight: normal` would make the text
still end up bolder than the ".lead" element). In these cases we need to
use the font-weight of said block.
It's an imperfect heuristic but it gets the job done in the vast
majority of cases.

Thus far, the editor only handled text-only pasting. This commit makes
it so that it now handles html pasting, and ensures that text pasting is
properly escaped (to prevent evaluating html strings on paste).
When pasting html, the editor filters the nodes, their attributes and
their classes through a combination of a whitelist and a blacklist.
Nodes that match blacklisted or non-whitelisted selectors are removed
and their contents are unwrapped recursively. Attributes and classes
that are blacklisted or non-whitelisted are removed.
What is kept are basic styling elements (eg: h1, strong, ...), images
(with their src attribute), links (with the href attribute), and a
selection of classes the edition of which is supported by the editor.

When pasting a paragraph within a paragraph, the original paragraph
should split rather than allowing for nested paragraphs.

Clicking in the (non-floating) toolbar, then on one of its buttons would
edit the toolbar itself (eg., clicking on a list button would insert a
list in the toolbar).
This adds a check on toolbar events so they can only affect what is in
the editable area.

This addresses a bug that occurs when selecting over two paragraphs that
are separated by some whitespace. It would create multiple indented
lists.

Task: 2567795

When inserting HTML, we sometimes need to split blocks to prevent weird
nesting of blocks. However, that process has the potential of generating
shrunk blocks (blocks without a height), such as <p></p>. This prevents
it from happening.

The sanitizer merges similar elements together but <option> elements
should never be merged because they each represent a separate option,
no matter if several consecutive options are the same. Options are
blocks by default so failing to recognize that was the cause of the
issue.

Sometimes Google Chrome wrongly triggers an input event with `data`
being `null` on `deleteContentForward` and `insertParagraph`. Luckily
Chrome provides the proper signal with the event `beforeinput`.

A fix had already been made for enter but not for `deleteContentForward`.

The system to detect if the text that was pasted contained javascript or
xml was weird, buggy and risky. This reverts it so we can make use of
insertText instead of insertHTML and be perfectly safe. We also preserve
linebreaks in HTML.

When inserting blocks, we often need to split the node in which we're
inserting. The code that makes that happen had an issue in its while
statement that checked the wrong node, resulting in overreaching splits.
This fixes that while statement.

REASON FOR THE FIX
To correctly display the overlay over a rotated element, we need to
reset the transform of the element, to be able to apply it on the
overlay.

Changing the style of the element in the SnippetEditor cover method
would trigger a DOM mutation, which will result in setting the
odooEditor observer unactive.

The issue was that flushing the observer (when setting it unactive)
would always send an event observerApply, even if no record was
processed.

It was an issue as the SnippetsMenu was triggering a content_changed
event at the reception of this event, which would rerender the
SnippetEditor overlay cover (and create an infinite loop of events).

SOLUTION
To avoid that, the observerApply event is sent only if records were
processed.

task-2554608