[PP-1] Move away from derivatives for FieldBlock and instead use block settings

Problem/Motivation

Splitting this from ✨ Add the notion of a 'configured layout builder block' to solve a number of content-editor and performance pain points Active and 🐛 Reduce the number of field blocks created for entities (possibly to zero) Needs review

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 📌 Remove blocks that are not useful within Layout Builder Fixed #2977587: Improve block listing in Layout Builder by hiding uncommon block plugins →
• 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 → 🐛 Reduce the number of field blocks created for entities (possibly to zero) Needs review

Proposed resolution

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

• 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 enabled, field block deriver continues to run as is.
• 🐛 Reduce the number of field blocks created for entities (possibly to zero) Needs review in it's current form can still proceed as it does improve the scenario for sites in legacy mode.
• With legacy mode off, no field blocks are derived
• Instead a new block plugin is made available per #3043330-95: Reduce the number of field blocks created for entities (possibly to zero) → idea that basically encapsulates an entity type, bundle, fieldname and formatter/configuration for the field. The bundle field should support multiple values to allow re-use of a formatter across multiple bundles. Eg. you would not want to configure one instance of a 'short date' block for every node type.

Remaining tasks

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

User interface changes

API changes

Data model changes

Release notes snippet