Block library: Standardize file structure of core blocks

[gziolo]

Description

This is trying to bring the structure of core blocks closer to what is proposed in block registration RFC #13693. In particular, it ensures that:

• all edit methods are moved to their own file
• all SVG based icons are moved to their own files

Extracting SVG icons is going to be a good step towards exploring how #14628 could be achieved as all SVG based icons would be located in their own files making it easier to reason how to convert them to the current form from the commonly known file format.

Testing

Ensure all block icons in the inserter display as before for core blocks.

Follow-up task

• Perform the same refactoring for save methods as well.
• Investigate what to do about all other client-side properties like transforms or merge.

[ellatrix]

Sometimes we seem to set these as constants, other times not. Would it be good to standardise this too? Personally, I feel like the constants are good, but a separate file for it a bit too much.

[gziolo]

Yes, we should both ensure they are provided and figure out what's the best way to encode them. We can't use constants inside block.json files but maybe it would be possible to create ESLint rule which would ensure that identifiers use the existing attribute's name.

[ellatrix]

Looks good. Personally I think the contants file is a bit too much, especially if we will have them for all blocks.

[gziolo]

Looks good. Personally I think the contants file is a bit too much, especially if we will have them for all blocks.

As it turns out in #14770, I figured out that constants don't play well with block.json so I think we will have to remove them altogether to be able to move attributes to block.json. I will revisit the approach for constants when I have a better idea how blocks can consume JSON metadata.