Integrate experience builder with entity-custom-elements-generation

As a preparation for figuring out how to integrate best, here is an AI-based summary of how XB takes over entity generation.

I do think the best and right now also the easiest way to do this is by adding a new, dedicated ce-field formatter.

The frontend can take care of showing the XB-content as a full-page and deal with other fields as needed.
This goes inline with the layout-builder integration which we recently improved to have fields next to the layout, so just keeping the output as yet another field makes sense.

I'd not use the "auto" processing to support, with the formatter we are more flexible when we need settings in the future + the existing "auto" output might be an interesting alternative for some folks, it's a verbatim output of the internally stored structure, let's better keep that there.

What probably makes sense is that we take care of auto-configuring the formatter properly in the future, so the auto-configuration based upon the field-type is something we might want to look into, but that's a generic improvement, and not in scope of this task.

Code looks good and provides a relevant Kernel test. RTBC

I figured the resulting structure is weirdly nested though, this needs improvement. I'll take a stab on it before merging this.

I figured we need a way to make the normalize flatten a custom-element with slot-content in a way that the custom-element turns into a list of custom element elements. Without that it would become tedious to flatten things, since do not want to have a helper like convertRenderArray() to return null|¢ustomElement|CustomElement[]. We should be able to organize a list of custom elments in a single object, that helps to keep code clean.

Thus I'm taking a stab on adding this here. I'd call it "renderless-container", similar to the concept of "renderless-components" in the frontend world. This is not very nice, but expressfull, so when you run into it it should be clear what it is. Since the element is not rendered, we cannot really render the attributes either, so the result is that it only renders the children/slots.

ok, new MR is ready with a couple of improvements/fixes:

- adds new renderless-container for better wrapping of multiple children, as described above
- adds template-suggestion for overriding markup output by tag
- implements renderless-container in both markup and json serialization + adds test-coverage for that
- improves XB field-formatter to avoid nesting, XB-fields are single-valued
- improves XB-field-formatter test to assert the flat structure when renering multiple components

I reviewed the MR 127. Let's get it merged before 📌 Leverage renderless-container for simpler code Active .

The only remark that needs another look is from the .module file (template suggestions but the only template there currently exists is for renderless-container).

Thx merged I'm going to rebase the other MR then.

> The only remark that needs another look is from the .module file (template suggestions but the only template there currently exists is for renderless-container).

Yes, it generally allows you to add a template for special custom-element, e.g. you could add "custom-element-drupal-markup" if somehow you want to customize it. I think that makes sense and comes with no down-side compared to only adding a single suggestion.