Refactor onChangeEditableValue handling (version1)

[atimmer]

Description

In #11861, @iseulde pointed out that ideally RichText should not 'know' anything about custom formats. So the handling of onChangeEditableValue should move to the rich-text package. Specifically the create function.

This is an attempt to execute this refactor. It works functionally, but the implementation has a ton of duplication. The problem I was trying to solve was that toFormat strips the relevant information we need when building the list of formats for the value. So to circumvent this, I build another array with shadowFormats that contains all formats that are actually in the DOM.

This shadowFormats array is then send to onChangeEditableValue.

Note: The actual onChangeEditableValue in RichText needs to move too, but I wanted to have these versions out asap to address the complexity and moving that function itself over is trivial so can be done after choosing how to refactor.

How has this been tested?

The e2e tests still pass, I have tested that annotations still work.

Screenshots

Types of changes

Checklist:

• My code is tested.
• My code follows the WordPress code style.
• My code follows the accessibility standards.
• My code has proper inline documentation.

[gziolo]

@atimmer and @iseulde is this is something that is still necessary now that 5.0 was released? I'm adding Stale label to make it easier to triage open PRs. Feel free to remove if you plan to continue work on this PR.

[ellatrix]

Yeah, I need to look into it when I find some time...

[ellatrix]

Fixed in #14284.