Bug 1815969 - part 5: Make editors handle pasting something in new focused...

Bug 1815969 - part 5: Make editors handle pasting something in new focused editor if a `paste` event listener moves focus r=m_kato

If a `paste` event listener moves focus, Chrome makes new editor keep handling
the pasting.  For the compatibility, we should follow it unless the new focused
element is in different document because user should allow to paste it
explicitly.

On the other hand, this just stops handling "cut" in same situation because
handling it requires to update clipboard without user's activation.  Therefore,
the clipboard content and/or the new editor content may be lost from the users
point of view.

Note that `nsContentUtils::GetActiveEditor` may return `HTMLEditor` instance
when focused element does not have `TextEditor` even when non-editable element
has focus.  Therefore, if it returns an `HTMLEditor`, we need to check whether
it's active in the DOM window with a call of `HTMEditor::IsActiveInDOMWindow`.

Differential Revision: https://phabricator.services.mozilla.com/D176741