Feature: Extbase plugin rendering 

Description 

A third-party Extbase plugin now renders on an installation using this theme, whether it is registered as a dedicated CType (the way TYPO3CMSExtbaseUtilityExtensionUtility::configurePlugin() recommends, and the only registration TYPO3 v14 accepts) or, on TYPO3 v13.4 only, through the historical General Plugin / list registration.

configurePlugin() generates tt_content.<pluginSignature> =< lib.contentElement for every plugin, unconditionally, on both installed core versions - even on v14, where nothing outside this theme defines lib.contentElement at all, because fluid_styled_content is not installed there. Before this change nothing rendered that object's templateName = Generic, so every such plugin fell through to TYPO3's own "no rendering definition" notice, indistinguishable to an editor from a broken content element.

Resources/Private/Templates/Generic.html is the new template that fixes that - shared by every plugin regardless of extension, because templateName = Generic is a fixed string the core writes itself, not something a plugin author controls. It reads back the per-plugin 20 cObject the core places beside templateName at a path built from the record being rendered (tt_content.{data.CType}.20), rather than a fixed one, so the one template serves every plugin without knowing which one it is.

General Plugin / list 

TYPO3 v13.4 still offers the historical registration TCA (types.list in EXT:frontend's own Configuration/TCA/tt_content.php), deprecated but present (Deprecation forge#105076). fluid_styled_content supplied the tt_content.list object that rendered it, as a CASE keyed on the plugin's Type (list_type) field, and removed it outright in v14.0 together with the list CType itself (Breaking forge#105377). This theme now supplies that object too, in its own house style, reusing the same Generic.html template - a list record's own CType is list, so the same {data.CType}.20 path resolves to the CASE rather than to a single plugin.

It is declared unconditionally rather than behind a version condition: on v14 the list_type database column itself was dropped along with the CType, so nothing can ever reach the branch - verified directly against the installed v14.3.6 core, not only argued from the changelog. See docs/architecture/content-elements.md in the developer documentation for the full verification and the reasoning for leaving it unconditional.

Impact 

An Extbase plugin registered by a third-party extension - one this theme does not control the TypoScript of - now renders instead of the core's "no rendering definition" notice, on both TYPO3 v13.4 and v14.3, regardless of whether it is registered as its own CType or, on v13.4, through the historical General Plugin type.

Tests/Functional/Fixtures/Extensions/plugin-fixture is a fixture extension that registers a plugin with no TypoScript rendering definition of its own - unlike Tests/Functional/Fixtures/Extensions/ example-fixture, which deliberately overrides what configurePlugin() generates - so the only thing that can make it render is this theme's own lib.contentElement and Generic.html.