[PP-1] Experiment: Adapt existing layout builder storage model instead of starting fresh

Problem/Motivation

We know we're going to need to support blocks in our data model - see #3454519: [META] Support component types other than SDC, block, and code components
We also know we're going to need to support SDC components.
In #3454519: [META] Support component types other than SDC, block, and code components we're talking about ways of supporting both. This will require introducing a config entity that wraps a plugin. But we already have that in blocks. And we already have a storage layer that supports blocks - in layout builder.

We also already have prior art for placing SDC components in layout builder via SDC block. This however does not allow storing/mapping SDC props to entity fields. Component blocks however, does support wiring component props (albeit via UI patterns v1) to entity fields. It also makes use of the block API's context integration to support linking to fields in context. This means you can render components based on the author of a node, not just the node. We also know we will need formatter support for entity fields. For example - it's not enough to say 'use this image', we need to be able to say 'use this image with this image style'. Component blocks module already supports this, as well as static props and tokens.

Another side-effect of this approach would be a smoother upgrade path. We already have modules like layout builder browser, layout builder restrictions that deal with block entities. We can support existing layouts in place without needing a slow and complex update path.

But there are limitations in the layout builder data model.:

1. It does not support nested layouts
2. It does not support asymmetric and symmetric translations

So the experiments so far have only considered a greenfield approach to the data model based on #3440578: [PP-2] JSON-based data storage proposal for component-based page building.
There haven't been any experiments (at least not publicly) that attempt to evolve the layout builder data model to address its limitations.

Proposed resolution

1. Write an extension to layout builder section field item/list and swap that class in via an alter hook
2. In that class, add two additional columns and a computed property that are the same as the new component tree field in the 0.x branch
3. When the new columns are empty, we can assume the data is legacy, and load and transform it from the existing section list column. When we next save this entity, we can write to the new columns, in the new format
4. When the new columns are not empty, we can use the new data model
5. With this data model in place, we get the translation support desired for XB but with a smooth update path. We also solve the 'how do we support other component types' issue
6. With this data model in place, we get nested layout support - the old legacy layouts don't support nesting - but the new model does.
7. Adapt the component block module's component block into a new block-type that takes the best of SDC block and wires it up to support entity field mappings
8. At present Component block module maps a formatter to an entity field - as XB aims to also support editing we will need to extend that to also support widgets
9. Adapt the existing component config entity in the 0.x branch to the same use-case as #3365551: Add the notion of a 'configured layout builder block' to solve a number of content-editor and performance pain points - it will store the default configuration of a block, and the regions it can be used in. This allows the site builder to decide what can be used where.

Remaining tasks

This should be a small scale experiment. Items 1-7 of the proposed resolution need to be done in order to demonstrate it could work.

User interface changes

API changes

Data model changes