WIP: Add dynamic block

[dmsnell]

In #4591 we build a custom parser for Gutenberg blocks whose intent was to skip building the entire parse tree and to replace dynamic blocks with their server-rendered output. This custom parser is designed to be faster than the full parse.

This custom parser has served well thanks to the work @aduth put into it but it diverges from one of the project goals, which is to have a clear semantic for how post_content translates in the editor and in page views.

This PR is an attempt to "internalize" or "build natively" that same parser into the existing post grammar. Since the grammar defines concepts shared among the different parser productions we can overlap their code and keep the two in sync more easily when we remove that duplication. The PEG is also a bit more declarative and in my opinion easier to follow intent.

The main distinctions in these new rules and the main method of parsing follow:

• Everything is either a dynamic block, a normal block boundary, or content to feed to the rendered output
• Replace dynamic blocks with the rendered output from the server
• Strip away all other block boundaries
• Leave everything else

Although my instinct tells me that this should be considerably faster than the default parser I don't have any measurements. That's being worked on thankfully in #6030 and other efforts right now to polish the flexibility of the parse system.

Currently this doesn't replace dynamic blocks with server-generated content but rather with the string dynamic. It would be helpful to me if someone could point me to an efficient way to find the right render callback and feed in the block attributes to it.

[mcsf]

👋 ❗️

Currently this doesn't replace dynamic blocks with server-generated content but rather with the string dynamic. It would be helpful to me if someone could point me to an efficient way to find the right render callback and feed in the block attributes to it.

From lib/blocks.php, you could do:

// Make implicit core namespace explicit.
$is_implicit_core_namespace = ( false === strpos( $block_name, '/' ) );
$normalized_block_name = $is_implicit_core_namespace ? 'core/' . $block_name : $block_name;

// Find registered block type. We can assume it exists since we use the
// `get_dynamic_block_names` function as a source for pattern matching.
$block_type = WP_Block_Type_Registry::get_instance()->get_registered( $normalized_block_name );
$dynamic_output = $block_type->render( $attributes );

[dmsnell]

Closing in favor of a new "default" parser implementation in #8083 which should make full server-side parsing an option