`ComponentTreeStructure` data type: simplify the stored structure

Overview

In @longwave's review of #3461490: Document the current JSON-based data model, and describe in an ADR, he pointed out:

If the structure was something like this it reduces special-casing of the root and allows for possible future expansion:

{
  "ROOT_UUID": {
    "component": "root",
    "slots": {
      "root": {
        "uuid-root-1",
        "uuid-root-2",
        "uuid-root-3",
      }
    }
  },
  "uuid-root-1": {
    "component": "provider:two-col",
    "slots": {
      "firstColumn": [
        "uuid4-author1",
        "uuid2-submitted",
      ],
      "secondColumn": [
        "uuid5-author2",
      ]
    }
  },
  "uuid-root-2": {
    "component": "provider:marquee",
    "slots": {
      "content": [
        "uuid4-author3",
      ]
    }
  },
  "uuid-root-3": {
     "component" : "provider:no-slots"
  },
  "uuid4-author1": {
     "component" : "provider:no-slots"
  },
  "uuid2-submitted": {
     "component" : "provider:no-slots"
  },
  "uuid5-author2": {
     "component" : "provider:no-slots"
  },
  "uuid4-author3" : {
    "component": "provider:no-slots"
  }
}

ie. we treat root just as another component which is really just a list of other components, and move component inside its own component UUID instead of keeping it with the slot definition? Then we can treat the slot definitions as a simple array of UUIDs.

This seems both flatter and simpler than the proposed structure but not sure if it has any disadvantages?
If it turns out we need to store something else in here we can do it at the third level alongside component and slots?

Proposed resolution

I agree with @longwave that this simplification makes sense — it'd also simplify various other pieces:

• the validation logic introduced in #3460856: Create validation constraint for ComponentTreeStructure
• the tree reconstruction logic for the hydration logic introduced in #3463986: Refactor SdcController::preview() to use ComponentTreeHydrated, and update it to support nested components

… and thanks to the test coverage that was introduced there, this would actually be very simple to evolve the structure towards! 🥳

User interface changes

None.