Blocks: Add support for block name aliases for variations

[gziolo]

What problem does this address?

Part of Block API roadmap #41236.

Let's explore whether some block variations can be read as a block type. For example, instead of core/template-part/header be able to just have core/header to still get resolved by the template part functions. We used to have a similar granular naming schema for Embed and Social Link blocks before we converted them to block variations:

https://github.com/WordPress/gutenberg/blob/bdb6a41099529541ce1f35d05037fef066674150/packages/blocks/src/api/parser/convert-legacy-block.js#L23-L29

https://github.com/WordPress/gutenberg/blob/bdb6a41099529541ce1f35d05037fef066674150/packages/blocks/src/api/parser/convert-legacy-block.js#L31-L50

Benefits of using aliases

• Aliased block names would get converted into unique class names assigned to block variations, giving more options to style their sites.
• Manipulate in theme.json granularly (like attach custom CSS that only is used when the block is used, etc.).
• Aliases used would give easier access for site owners to the content analysis of which blocks and variations are used in posts and templates.
• Benefit from all the block API tools in existence (like multiple block support).

What is your proposed solution?

Add handling for block type name aliases used with block variations. They should fall back if necessary to the original block type name, e.g. woocommerce/product-list that can get resolved to the product-list variation added to the core/query block.

Some examples to consider:

<!-- wp:template-part {"slug":"header","theme":"twentytwenty"} /-->
<!-- wp:meta { "name": "mykey", "type": "heading" } /-->

becomes

<!-- wp:template-part/header {"theme":"twentytwenty"} /-->
<!-- wp:meta/mykey { "type": "heading" } /-->

This could also remove the need for complex logic used with block variations when detecting the variation based on the result of the isActive callback executed.