TYPO3 Core

I stumbled over an inconsistency in the frontend rendering definitions. This time it’s the API based registration of content elements with `Extbase` and `addPItoST43`.

Problem is that fluid_styled_content and css_styled_content have different needs for structuring the typoscript definitions for content element rendering when it comes to user functions.

The generated structure is always more or less the same for now.

```
tt_content.myce = COA
tt_content.myce {
10 =< lib.stdheader
20 =< plugin.myContent
}
```

This means that a rendering the header relies hardly on the existence of lib.stdheader, that is not available anymore in fluid_styled_content. Even if we would make it available again the wrapping divs, anchors, frames, spacebefore, spaceafter, linktotop etc. will still be missing for the registered content elements.

Unlike plugins, content elements do not have a single ctype that we can easily modify by adapting it later in the rendering definition of fluid_styled_content because we do not know the keys and blindly iterating over the typoscript and guessing what will happen could lead to very unwanted results and missbehavior.

We still have to support css_styled_content and fluid_styled_content we have to find a solution that fits both and is not heavily breaking. I´ve already tried a lot, and I think I have a working solution that fits all needs. Still we need to change stuff a bit.

Idea is that we utilize a new typoscript lib object that is existing in both css_styled_content and fluid_styled_content. Its more or less the same that we already have with `lib.fluidContent` but with a more generic naming like `lib.contentElement`. This would ensure it can be used across all rendering definitions without being too explicit about the naming, and can be adjusted to the needs of the content rendering definitions – that means a twig integration would not need to fiddle around with `lib.fluidContent` so we can avoid confusions now and probably do not need to change it again in the future.
Adjustments on PHP Side would be rather easy.

```
tt_content.myce = < lib.contentElement
tt_content.myce {
templateName = Generic
20 = < plugin.myContent
}
```

In short that means we just add `10 <= lib.stdheader` with the for css_styled_content, since COA has no use for templateName, it will simply be ignored and everything works as before. It will be no breaking here.

For fluid_styled_content we would rename `lib.fluidContent` to `lib.contentElement` and make `lib.fluidContent` available again as copy of `lib.contentElement` so that we avoid break custom content elements that currently utilize `lib.fluidContent`.

Worst thing that can happen here is that the typoscript constants for template path adjustments were ignored and lib.fluidContent was modified directly. Migration would be rename your adjustments from lib.fluidContent to lib.contentElement.

Please see review for this issue.