[FIX] web: fix colorpicker position in iframe

Issue:
======
Colorpicker doesn't appear in mass mailing

Steps to reproduce the issue:
=============================
- Create a new mass mailing with a some template other than plain text
- Try to change the color of some text
- The position of the colorpicker is wrong.

Origin of the issue:
====================
When wysiwyg was converted to owl in [1], an effort was made to
speed up the loading of the iframe in mass_mailing. One of the
changes that were done in that regard was to remove assets from
the iframe to make it load faster. This required to create the
sidebar (SnippetsMenu) outside of the iframe since the iframe did
not have the required files anymore, and insert it back in the
iframe afterwards, since it was designed to work inside the iframe.

This change actually had an impact on the positioning of the
colorpicker, and basically anything that relied on popper.js for
positioning, because since popper.js was outside of the iframe then
the checks it did based on `instanceof HTMLElement` were returning
false for every node inside the iframe. At the time of [1] this
went unnoticed because the chatter was not yet in the side of the
screen for mass_mailing, so the wrong positioning of the colorpicker
was actually only slightly off the right position, thus being hard
to catch while not specifically looking for that particular issue.

As soon as the chatter was made to be on the side even in the case
of mass_mailing, the wrong colorpicker position became visible but
the issue went unnoticed at the time as well, probably because the
two changes were completely unrelated. This went live in saas-16.4
and is the case in 17.0 as well. However, the issue does not exist
anymore in saas-17.1 due to the refactor of mass_mailing to have
the sidebar (SnippetsMenu) working from outside of the iframe
instead of inside.

Solution:
=========
Fixing this issue properly would require huge changes to how the
SnippetsMenu is constructed and would most likely require going
back to the slow iframe with all the assets inside. That would not
be a desirable outcome, especially in a stable version. With that
in mind, and considering the issue doesn't exist in saas-17.1, we
decided it was a prime example where a local change in the popper.js
library was actually the best fix. The library is very unlikely to
be updated in a stable version and the change won't reach saas-17.1.

[1]: https://github.com/odoo/odoo/commit/76d4f98
co-authored with dmo-odoo

task-3614965

closes odoo/odoo#162964

X-original-commit: 88c16966b6b2d29d464ac3b43cc4998d3f4fe0e2
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Signed-off-by: Mahdi Cheikh Rouhou (macr) <macr@odoo.com>

addons/web/static/lib/popper/popper.js

@@ -28,7 +28,9 @@
 
   function isHTMLElement(node) {
     var OwnElement = getWindow(node).HTMLElement;
-    return node instanceof OwnElement || node instanceof HTMLElement;
+    // Updated to handle checks of HTMLElement created in a different document
+    // which is required to position the colorpicker correctly.
+    return node instanceof OwnElement || node.nodeType === Node.ELEMENT_NODE;
   }
 
   function isShadowRoot(node) {