Block Hooks: Apply to content-like Custom Post Types

[Bernhard Reiter]

Per [59523] and [59543], Block Hooks are applied to post content and synced patterns, respectively.

This involved adding update_ignored_hooked_blocks_postmeta to the rest_pre_insert_* hook (for the page, post, and wp_block post types), and insert_hooked_blocks_into_rest_response to the rest_prepare_* hook (for the same post types).

The downside of adding those filters to those hooks on an individual post type basis is that Block Hooks are only applied to those post types, but not to user-defined Custom Post Types; extenders would have to do so themselves.

Arguably, they shouldn't have to; Block Hooks should work out of the box for a CPT (assuming that it is a "content-like" CPT). We might thus want to consider inlining the code from those two functions into the Posts REST API controller (namely, into the prepare_item_for_database and prepare_item_for_response methods, respectively). We can consider adding some criteria to make sure that Block Hooks are aren't accidentally applied to ancillary post types, such as the ones used for Global Styles.

Furthermore, the two aforementioned functions now contain logic to map a given post type (e.g. post or wp_block) to the corresponding block type (core/post-content and core/block, in this example). This is required so that the block markup can be temporarily wrapped in a block of that type, thus allowing Block Hooks to insert hooked blocks as the first or last child of the containing block.

These mappings should be filterable by the user, so that the user can extend them to include custom-defined post types and block types, respectively -- or to remove mappings, if needed.

(Stretch goal: In the future, we might want to use these mappings to (partially) unify the implementations of blocks like Post Content, Synced Pattern, and possibly Navigation and Template Part, which all render content that they get separately from the database.)