🐛 Run clipboard matchers against plain text pastes

[alecgibson]

This is a reimplementation of #3530

At the moment, if the clipboard pastes text/plain content and no text/html content, the Clipboard.convert() function will completely skip the matching logic.

This is surprising when registering text node clipboard matchers.

This change updates the convert() function to match the plain text against the plain text matchers, just like we do with HTML.

Note that these matchers will run before applying the formats for "paste and match style", so they won't match an element matchers for the target formatting (which I think should be expected anyway).

[luin]

It fails when text contains \n as it converts it to spaces. Added test cases: #4005

Come to think about it, I'm not sure if it's technically correct to say a plain text is a Node.TEXT_NODE, as it's not a part of an HTML document at all.

I think we can keep this part as is, and for users who want to change the behavior can override the convert method and apply their handlers. WDYT?

[alecgibson]

I guess that's a fair comment that it's not technically yet a TEXT_NODE (even if it's about to become one...).

I think I personally find it a bit surprising (hence the PR), and it's a shame there's no entrypoint to just handle pasted "text" (eg if you want to turn ... into …; linkify URLs like in the unit test; strip unwanted characters like weird whitespace; etc.). I think it leads to inconsistent pasting behaviour if consumers aren't careful.

In future I think I'd argue for either renaming Node.TEXT_NODE -> 'text', or at least adding a 'text' matcher type that would match both TEXT_NODE, and plain text pastes.