FieldType: Support storing component *trees* instead of *lists*

Problem/Motivation

\Drupal\experience_builder\Plugin\DataType\ComponentTreeStructure::$tree (used by \Drupal\experience_builder\Plugin\Field\FieldType\ComponentTreeItem) can currently only store lists of components:

  /**
   * The parsed data value.
   *
   * @var array<int, array{'uuid': string, 'type': string}>
   */
  protected array $tree = [];

its values look like this:

[
  {"uuid":"dynamic-image-udf7d","type":"experience_builder:image"},
  {"uuid":"static-static-card1ab","type":"sdc_test:my-cta"},
  {"uuid":"dynamic-static-card2df","type":"sdc_test:my-cta"},
  {"uuid":"dynamic-dynamic-card3rr","type":"sdc_test:my-cta"},
  {"uuid":"dynamic-image-static-imageStyle-something7d","type":"experience_builder:image"}
]

— citing config/optional/field.field.node.article.field_xb_demo.yml

This means it is currently unable to record which components are placed in which slots — all components are effectively placed in the virtual <root> slot! Which is why … it's not a tree, but a list.

This blocks #3446722-14: Introduce an example set of representative SDC components; transition from "component list" to "component tree".

Steps to reproduce

N/A

Proposed resolution

• Update \Drupal\experience_builder\Plugin\DataType\ComponentTreeStructure::$tree to support storing a tree, like this:
  

  {
    "<root>": [
      {uuid: <uuid1>, component: "provider:two-col"},
      {uuid: <uuid3-standfirst>, component: "provider:marquee"},
    ],
    "<uuid1>": {
      firstColumn: [
        {uuid: <uuid4-author>, component: "provider:person-card"},
        {uuid: <uuid2-submitted>, component: "provider:elegant-date"}
      ],
      secondColumn: [
        {uuid: <uuid5-main-image>, component: "provider:image-hero"}
      ],
    }
  }
  

  with <root> being a UUID too, but one that is hardcoded as a constant:

  class ComponentTreeStructure extends TypedData {
    const ROOT_UUID = '…';
  }

• No update path.
• Update \Drupal\experience_builder\Plugin\Field\FieldWidget\TwoTerribleTextAreasWidget accordingly, to ensure editing remains possible.
• Update config/optional/field.field.node.article.field_xb_demo.yml and EndToEndDemoIntegrationTest accordingly, to ensure that upon installation in the Standard install profile, XB continues to provide the exact same demo experience.
• Validation constraint for ComponentTreeStructure, see https://git.drupalcode.org/project/experience_builder/-/merge_requests/6...

Remaining tasks

All of the above.

User interface changes

Yes: TwoTerribleTextAreasWidget supports more, but it can stay equally terrible.

API changes

N/A

Data model changes

N/A