Add the notion of a 'configured layout builder block' to solve a number of content-editor and performance pain points

Problem/Motivation

There are currently a number of pain points with Layout Builder and how it interacts with the block plugin system as follows:

• without layout builder restrictions module the default number of blocks available to a content editor is overwhelming #3040348: Remove blocks that are not useful within Layout Builder #2977587: Improve block listing in Layout Builder by hiding uncommon block plugins
• without layout builder browser module the UX of the list of blocks isn't great. There is the main list of blocks, which is grouped by categories that don't necessarily make sense, e.g. 'Core' might not mean anything to a content editor. Creating inline blocks is probably the most common function, however that is hidden behind an additional link. Site builders cannot group and rename blocks to suit the site #3069446: Layout builder's "Add Block" sidebar menu UX improvements. Adding icons would break up the list #3010494: Custom images for the layout builder side panel#3111973: Use granular entity type bundle driven field block categories when choosing blocks
• too many field block plugins is overwhelming to the editor and causes performances issues. For example would the editor ever need to place a revision log block? In addition we generate field block plugins for every bundle, field and content entity combination, many of them may not even have layout builder enabled #3257671: Allow an opt out of specific fields from the layout builder UI#3043330: Reduce the number of field blocks created for entities (possibly to zero)
• Additionally, all of the field block plugins expect the content editors to configure a formatter, which is unreasonable. Site builders would prefer to create pre-configured blocks such as 'Short post date' or 'Long post date' and avoid giving these options to content editors.

Proposed resolution

• Per #3043330-95: Reduce the number of field blocks created for entities (possibly to zero) Add a 'legacy mode' settings flag to layout builder.
• Enable this for existing sites.
• With this flag on, a new config entity 'configured layout builder block' is available. This encapsulates
• • the functionality of layout builder browser (block order, block icon, configurable block category, configurable block label)
  • functionality of layout builder restrictions (which regions and sections it can be used in. At present Layout builder restrictions manages this on the view mode configuration but this is overwhelming and often results in a lot of merge conflicts for config YML files. Flipping the restriction management from being on the view display to on the block will reduce this pain and also simplify the UI of adding restrictions. The current UI in contrib is a series of expanding/collapsing details elements and modals to allow for all the possible blocks and sections.
• Be sure to store the regions/section data in a way that would allow onDependencyRemoval to work (E.g. key sections/layouts by provider) and allow reacting to modules providing layouts being disabled.
• Create a configured layout builder block map service, like we have for field map, that would be performant to query which blocks are available for which sections and regions given an entity context.
• When configuring these 'configured layout builder block' config entities, allow the site builder to preconfigure and hide block config options from the content editor - this would allow preconfiguring the new block entity-field block from above to set formatter options - or for example configuring a views block
• These 'configured layout builder block' config entities would also support adding the same field twice. E.g the example from above a 'short post date' and a 'long post date' could be preconfigured by the site builder.
• Having a pre-defined set of 'configured layout builder block' entities would allow front-end teams to work with a known set of options to ensure that everything available had an appropriate front-end representation.

See also #3387154: [PP-1] Move away from derivatives for FieldBlock and instead use block settings for more steps to improve this for field blocks

Remaining tasks

• ✅ Discuss the pain points with product managers (@lauriii, @gabor, @ckrina)
• ✅ Discuss the proposed resolution with subsystem maintainer (@tim.plunkett)
• Discuss the solution with maintainers of LB restrictions and LB browser
• Implement the solution with test coverage
• Reviews

User interface changes

API changes

Data model changes

Release notes snippet