Re-evaluate the need for slot normalization styles

Slot normalization styles are used to simplify the generated JSON content format of a custom elements tree. Atm, it's internally used and auto-activated when someone uses a setSlot() or setSlotFromCustomElement() call without an index (default). The result is that the e.g. a slot named "image" with a single custom-element for that image will result into a JSON object with the image-CE output being set as the property "image". Without slot normalization styles, it would be an array with a single entry, which then is the image-CE output.

The need for this came up to make the JSON output nicer when a lots of slots are used. However, since the creation of the module we moved more and more away from using a lot of slots. Slots are good for nesting arbitrary kind of (CE-) markup, but they are not needed when simply a nested data structure (like an image object) is to be created.

For the use-case of creating an image object, a custom-element is not needed, since when rendering a CE the FE does not not know what it will contain, so it loses some control. But usually for rendering images, the FE wants to stay in control and e.g. be able to adjust the image output or e.g. add some custom classes to it.

That said, the CE is not needed for this use-case. But when creating nested data structures with CE the rendered-markup becomes more readable than without. When creating nested data structures with attributes, a rendered markup would contain ugly json-serialized data. Thus, there is some advantage in that practice of using setSlotFromCustomElement() with single-valued CE for passing nested data. This is for NORMALIZE_AS_SINGLE_VALUE.

But then, we also support NORMALIZE_AS_SIMPLE_VALUE and NORMALIZE_AS_SINGLE_SIMPLE_VALUE, which does the same but allowing normalizations like headline: "text", such that there is no wrapping element any more. I'd even argument now, this is counter-intuitive to have a slot to be normalized in a JSON that is not an object at whole, because it would not be render-able via the regular helpers for rendering custom elements any more.

Thus, I think we should keep supporting setSlotFromCustomElement() or setSlot into a single valued CE, but we should drop support for simple and single+simple slot normalziation styles. Given that we should simplify the code to only support the single-valued slot-normalization style.