First-class experience builder support

Very cool to see this happening! 🤩

I updated the proposed resolution with a more detailed implementation plan as well as 📌 Prototype rendering JavaScript components with Nuxt Active .

After solving the nuxt-based component rendering I was a bit hesitant we are on the right track here, since the traditional Drupal theme's site-layout is just coming into our way. After planning out the big picture, I think it can work well if we achieve the following:
* Make the full-page preview of XB directly use the frontend via iframe
* Somehow avoid showing Drupal-theme site-layout in XB canvas - make the editor provide a blank canvas.

We've got the basic process for CE-output for XB-pages implemented in custom elements 3.x-dev now. Given that, we can start taking care about more details, opened 📌 Improve mapping of SDCs custom elements Active for that.

So from a XB perspective we need to clarify how we know when a component is mapped to CE or rendered traditionally. I think, it would make sense to default two twig rendering for SDCs and to opt-in into CE rendering by some mechanism. That could be some UI or a cli tool similar to xb-cli that scans vue components and - based upon a certain naming pattern - registers them in Drupal.

So besides registration, the most convenient approach seems to be to simply apply a naming pattern. We need our registry of place-able nuxt-components anyway, so when we have a component matching the SDC-override naming pattern we can apply it as override.

That said, it seems the next step needed is a proper XB "component source" implementation for placing components + a registry of components to place. Our components would be JS-components that render the custom-elements (e.g. in JSON representation) with some glue-JS to load the nuxt bundle. However from a CE-perspective, we don't know how the CE is rendered either.

In XB, we'd only need a quite generic component source, that can take care of the following:
- Custom element name. Property/slot information can be 1:1 the component prop/slot information.
- Provide the custom element name + property/slot information to the preview script, by rendering it suitingly
- Attach the preview script implementation, i.e. the drupal library to load and attach. Needs a way to decide upon the right script to attach (e.g. Nuxt-CE-Previewer implementation).

So, in XB this could be some sort of generic JavaScriptComponent - that holds the reference to the drupal library/js to attach for rendering.
In custom elements, we'd need a new mechanism to generate the preview JS a given element.

Attach the preview script implementation, i.e. the drupal library to load and attach. The XB-component could simply store which drupal library to attach. Custom Elements module would have to take care of deciding upon the right script to attach (e.g. Nuxt-CE-Previewer implementation).

Since custom elements wants to support multi-site/domain module use-cases, we cannot hard-code the way to preview by component. However, it should be doable to implement a generic "custom_elements/preview-component" drupal-library which gets processed accordingly by custom elements, such that modules can chime into this processing and override the library based upon request/site-context.

following the rename