Block Editor: move selection state from RichText to the store

[ellatrix]

Description

Fixes #11616.
Blocks #11005 and #12002. Blocks making RichText a controlled component.

This is an attempt to move local RichText selection state to block-editor store.

RichText would have the following props:

• selectionStart: the selection start offset, similar to the textarea attrubute.
• selectionEnd: the selection end offset, similar to the textarea attrubute.
• onSelectionChange: the function that will be called when the selection changes.

Within blocks, this state is provided by context. Nothing changes for block authors.

In the block-editor store, the selection state will now include a rich text identifier and offset in addition to the block client ID.

Why?

• This will be needed if we ever want to read/write selection in RichText areas. Think:
  • Restoring selection after undoing/redoing changes.
  • Cross block selection.
  • Collaborative editing.
  • Plugins: How to select text/node inside block programmatically? #13976.
• Blocks making RichText a controlled component. This PR moves logic to set the caret position to the MERGE_BLOCKS action and removes it from RichText.

How has this been tested?

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.
• I've included developer documentation if appropriate.

[ellatrix]

Reason why these are no longer expected: the formatting toolbar is only available one the rich text field has selection. The buttons are useless otherwise. In master, they are useless as well, but they display because there is lingering local selection state, so the toolbar thinks that the rich text field is selected. If you select the block for the first time in master, there will also be no formatting buttons. See #13598.

[ellatrix]

This is no longer needed as the selection state is stored in block-editor and there can be no two identifiers at the same time.

[gziolo]

I will give it a spin and see how it works.

It might fix #7463 as well :)

[gziolo]

In comparison to the master branch it works at least the same. It might work better in some cases but it's hard to tell as it's complex. I recorded a screencast with the most complicated blocks which were causing issues, like duplicated controls, in the past:

It seems like the changes proposed should open possibilities to finally resolve #7463 which we tried to tackle a few times but it was extremely difficult to detect blur event when implementation of RichText was fully dependant on TinyMCE. Given that this issue exists in the master branch, I personally don't expect it to be fixed in this PR. However, I wanted to raise it as it might have some influence on how this PR is shaped in its final form. I'm leaving it totally up to you @ellatrix. Great work on the refactoring in this PR.