[later phase] PropShapes' JSON schema must match exactly with FieldType's storage format — what if you want to use another FieldType + Adapter?

Overview

📌 Centralize & standardize logic for constructing *PropSource objects + kernel test coverage Fixed added test coverage for adapters.
In #3461499-17: Support complex SDC prop shapes: introduce (Storable)PropShape to compute field type storage settings → + #19 we decided to use the example value of the component.

📌 [later phase] [PP-1] When the field type for a PropShape changes, the Content Creator must be able to upgrade Postponed made me realize something.

For now, that all works because every PropShape's JSON schema matches the data stored by the FieldType exactly.

Once that won't match exactly, two problems will arise:

1. the examples defined in the SDC's *.component.yml will not be a valid value for that FieldType → they will need to be adapted (not towards the prop shape, which adapters were designed for, but the inverse)
2. StorablePropShape will need to be able to return not just a StaticPropSource, but an AdaptedPropSource — and the Component config entity will need to be able to store that, too!

Proposed resolution

Either:

• Add support for defining not one but two adapters in StorablePropShape (and use the second adapter to adapt SDC's example values to the shape expected by the FieldType)
• Add a writable computed property to the FieldType that performs this transformation (see \Drupal\Core\Field\Plugin\Field\FieldType\EntityReferenceItem::onChange() for an example).

The latter requires no new XB infrastructure, but changes in FieldTypes.

The former requires new XB infrastructure, but no changes in FieldTypes.

User interface changes