Allow registering block type collections with a single function call

[flixos90]

#62002 introduced wp_register_block_metadata_collection() which allows to improve performance of block type registration by using a built PHP manifest file instead of individual block.json files for the block type metadata coming from a single source (e.g. Core or a plugin). See also the ​dev note.

With this function available, it feels somewhat odd that developers still have to individually call register_block_type() or register_block_type_from_metadata() to actually register their blocks, when wp_register_block_metadata_collection() already has all the context needed to do so for most scenarios.

Note: We can't change wp_register_block_metadata_collection() to automatically register the block types, since that would be a backward compatibility break. More importantly, it is still possible to pass $args to register_block_type() and register_block_type_from_metadata(), so we don't know whether the developer would want to use that or not.

Based on all the reference code out there though, it's reasonable to assume that the vast majority of block types is registered purely from block.json metadata and without additional $args. Therefore, it would be reasonable to give those developers the option to register all their blocks with just the single block collection registration call.

Allowing this would be a nice DX enhancement, as it would allow developers to rely entirely on JS changes afterwards. You could literally introduce another block type in your plugin and wouldn't need to modify PHP at all. Today, the only way to accomplish a JS-only approach for this would be to e.g. use glob() in PHP to find all block.json files, but that has a performance penalty and would kind of defeat the purpose of what wp_register_block_metadata_collection() is trying to solve.

cc @gziolo @mreishus who I discussed this with ahead of opening this ticket

[flixos90]

What @gziolo @mreishus and I discussed in Slack so far was to potentially add a flag to the new function, e.g. like so:

wp_register_block_metadata_collection(
        WP_PLUGIN_DIR . '/my-block-library/build',
        WP_PLUGIN_DIR . '/my-block-library/build/blocks-manifest.php',
        array( 'auto_register' => true )
);

This alone would be a quite straightforward change to make and already address what's outlined in the ticket.

Additionally though, there would be value in combining the block type asset metadata into this process as well. Today, many block type assets still need to be individually registered, and block types only reference the asset handles registered in PHP. For the registration, it is already established to generate files with the metadata ({file}.asset.php), so potentially this could be integrated into block.json files (and thus also the built PHP manifest) to simplify scaffolding a block, and in particular the block registration code needed, even more. See related Gutenberg issue ​https://github.com/WordPress/gutenberg/issues/46954.