Try: Block API: Remove children source in favor of HTML string

[aduth]

Author's note: This proposal has been the source of much inner turmoil, as I struggle to come to a decision on whether this is a good thing. At the moment, I have decided not to proceed with these changes, with further explanation below, and will proceed to immediately close it upon opening, with the intention that it could serve as a base for discussion or future reference.

---

Closes #2750

This pull request seeks to eliminate the children source from the block API, favoring instead for block implementer's to source html as a string. The children source was introduced as a means to represent the value of rich text, but is problematic for the reasons as described at #2750.

The changes here provide a graceful deprecation for all blocks which rely on the children source to upgrade automatically to the equivalent html source. This is demonstrated in not porting any of the core blocks leveraging children, save for a few blocks which are naughty in their implementations, bypassing the abstraction atop React to access inner props (e.g. quote, list).

I've come to a few conclusions in the work here:

• Consolidating sources could lead to a better developer experience
• But having some representation of a tree shape can be useful for...
  • Content analysis
  • Safety (sanitizing HTML as a string is arguably more fragile)
  • Environment independence (e.g. browser vs. mobile vs. JSON representation)
• Our current tree shape (React elements) is flawed
  • Cannot be easily serialized (e.g. transmitting via WebRTC for collaborative editing)
  • Cannot be easily represented on the server for block templating or default values
• Alternative representations may be preferable
  • "Vanilla" array
  • TinyMCE tree (note: not serializable, as its data structure is circular)
• But it is error-prone and non-performant to frequently transform between tree shapes
  • Markup -> Gutentree -> TinyMCE -> Gutentree -> React -> Markup
  • Transforming from a DOM tree to React tree requires maintaining lists like this or this

So what next?

• Ideally React would be less opinionated about element trees
  • Being able to easily adapt the vanilla tree to a React element, or accepted natively
  • Happily accepting attribute names as props without logging warnings. We shouldn't need to change class (DOM) to className (JS property, React), particularly if the element is only ever serialized to a string (no DOM reconciliation of node properties)
• In lieu of this, we can create our own alternatives and control the behavior: Try: Custom save serializer, Editable as array tree #4049 (custom serializer)
• Or just keep it as it is
  • With children as an array type, we have the flexibility to refactor the exact shape of the tree representation later
  • But to better support this, we may want to introduce a RichText.Content component, even if not currently necessary, since it ties us less to the value of children being a React element which can be inserted directly into a render result.