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

Problem/Motivation

Splitting this from #3365551: Add the notion of a 'configured layout builder block' to solve a number of content-editor and performance pain points and #3043330: Reduce the number of field blocks created for entities (possibly to zero)

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
• 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)

Proposed resolution

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

• 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.
• #3043330: Reduce the number of field blocks created for entities (possibly to zero) 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