[PP-1] Add typed value-objects for the component tree structure

This should also allow refactoring #3460856: Create validation constraint for ComponentTreeStructure to make it simpler 👍

Reviewed! (Review delayed due to #3446722: Introduce an example set of representative SDC components; transition from "component list" to "component tree", I explained this in my review on the MR.)

👍 Enjoy! 😊

Having introduced the very barebones ClientSideRepresentation object last night in #3484678: Simplify ComponentSourceInterface::getClientSideInfo(), introduce ClientSideRepresentation value object, and leverage it, and seeing the existence of both:

• #3499632: Remove `ClientServerConversionTrait` (C→S) and `ComponentTreeItemList::getClientSideRepresentation()` (S→C) in favor of (de)normalizers — to complement ClientServerConversionTrait that was introduced in ~2 months ago at #347856: Gallery module: page not found
• #3489772: [PP-1] Add a param converter and DTO for XB data model

… makes me realize that you probably just were able to see months into the future with this proposal 😅 🤩

I definitely could not. Not until #3491013: Rework layout API to separate components and slots and #3489899: Add support for global regions had landed, both of which clarified the client-side data model, and it:

• has its rationale documented at docs/adr/0005-Keep-the-front-end-simple.md
• has its structure documented at docs/data-model.md, section 3.4 UI Data Model: communicating a component tree to the front end

Now that all that is in place (i.e. we know the client-side data model), I can totally see the value of what this MR originally envisioned: the ability to "upcast" any data source into the data model expected by the client, which will allow loading it into the client and then saving it into an XB field.

That means I'm now somewhat disagreeing with point 1 of my August 8 comment at https://git.drupalcode.org/project/experience_builder/-/merge_requests/1.... Although I do still think it'd probably be more powerful/interesting to be able to convert to the server-side data model directly, I'm not sure that that is required or even sensible — because I suspect that we'd never auto-convert "Layout Builder data" to "Experience Builder data", but instead make the transition trivial, while still requiring a human to do so.

Conclusion: I think that what I wrote in August might be the ideal scenario from a migration path POV, but I doubt it's realistic to achieve perfection. To overcome that imperfection, we could require human intervention, which is exactly what your proposal achieves. Thoughts?

Yep, very much aware of that! :D

That's what I was referring to in #12. And it's that "require human intervention" question at the end I wanted to double-check you're on the same page for? 🤞

tagging for findability

AFAICT this will essentially have been implemented by #3468272: Store the ComponentTreeStructure field property one row per component instance, see #3468272-34: Store the ComponentTreeStructure field property one row per component instance.

Hm, that seems pretty different from just-in-time loading mentioned in the issue summary? Because that would be in the client-side data model, whereas everything here is about the server-side data model.

See also the discussion at your other issue, #3462238: Decouple tree storage, introduce tree storage plugins, which this seems to be converging with.

Can we keep only one of the two issues?