Introduce CustomElement interoperability for block types

[felixarntz]

Description

Addressing #17360, this is a port from #2791, migrating that PR to work within the current APIs and making a few adjustments.

Types of changes

• Introduce a CustomElement component, which accepts a tagName, attributes and variable other props. Internally it creates a custom element of tagName, and adds the attributes as HTML attributes, and all other props as HTML properties.
  • Contrary to the original PR, this component is intended for custom elements only, to keep it single-purpose. Whether or not to use that component should be decided by the consuming code.
• Check if a block type's edit property is a custom element tag name, and if so use the above component to render it instead of directly interpreting edit as a component.
• Support passing a custom element tag name for edit when registering a block type.

Considerations

• Note that the CustomElement component itself is very generic and technically not limited to the block editor. I'd like for us to consider whether we want to add it to the @wordpress/element package. I didn't want to do that without discussing first, but I think this being a workaround for something essential that React does not allow out of the box gives us food for thought whether we should include it in that package.
• The same applies to the isCustomElement() function, which goes together with the CustomElement component. Right now the function is even redeclared (we should definitely address that one way or another) because I wasn't sure where to put it (@wordpress/element would work) so that all areas where it's needed could access it.
• Alternatively, we could make these two its own package @wordpress/custom-element.
• We might want to also allow passing a custom element tag name as a block type's save. That would clarify the intent that you can easily use a custom element even for both variants edit and save (without having to do that of course). Today, an easy way the custom element could check whether it is in edit mode or not would be checking if a setAttributes property is present or not.

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.

[gziolo]

@aduth, you might be interested into reviewing this proposal 😃

[aduth]

To be honest, my opinion is that this is something which shouldn't be natively supported. While I can appreciate all of the reasons a developer might choose to use Custom Elements in general, the current direction of this project is very much entrenched in supporting the abstraction of @wordpress/element (with @wordpress/components, etc). Introducing this interoperability could send mixed signals as far as what should be expected to be supported (e.g. what about registerPlugin?). Furthermore, while it does require an implementation of some React-based intermediary, there's nothing to stop someone from using Custom Elements by mounting into a DOM node from the edit component. I could imagine some small utility to provide this support, distributed in the third-party ecosystem.