Make sure View components are automatically hydrated even if their component is registered after the connectedCallback execution

[luisherranz]

In order to make this hydration technique as solid as possible, it is important that it doesn't rely on any execution order. One of our goals is to support client-side navigations where both the new HTML (containing wp-block tags) and the JS files associated with those blocks can come in any other, including the DOM modification first (and therefore the connectedCallback execution) and the frontend component (JS file) later. We need to make sure that hydration works even if the frontend component is registered after the connectedCallback execution.

This doesn't need to be complicated. I think that if some blockType is missing from the registry, the connectedCallback can just annotate it somehow so the registry registerBlockType() can trigger the hydration manually when it receives that blockType.

Something like this:

connectedCallback() {
  if (blockTypes.has(blockType)) {
    hydrate({ blockType, element: this, ...});
  } else {
    // ... anotate for latter hydration
    blockTypesToHydrate.set(name, { element, ... });
  };
}

const registerBlockType = (name, Component, options) => {
  blockTypes.set(name, { Component, options });

  // Hydrate annotated blocks
  if (blockTypesToHydrate.has(name)) {
    const { element, ... } = blockTypesToHydrate.get(name);
    hydrate({ blockType, element, ...});
  }
};

---

Another thing that could cause a race condition could be the JS containing registerBlockType() and the components using it, but we can figure out if we need something else for that later.