Reading Extbase settings outside a controller is undocumented — and ConfigurationManager is @internal

[linawolf]

Split out of TypoScript reference #463,
which collects the ways an extension can read TypoScript. Four of its five
cases are documented or linked by now; this is the one that is not, and it
belongs here rather than in the TypoScript reference because it is about
Extbase.

The gap

ExtensionArchitecture/Extbase/Configuration/Index.rst explains the
configuration surfaces and how they merge, and $this->settings is
documented for controllers. What is missing is how a class that is not a
controller — a service, a validator, a ViewHelper, a command — reads those
same settings.

ConfigurationManager appears exactly once in the whole manual, and only as
a warning about something else:

This short notation triggers TypoScript parsing via the Extbase
ConfigurationManager. It should be avoided in backend context, for example
in backend modules.

— ExtensionArchitecture/HowTo/Localization/Fluid.rst:99

Why the obvious answer looks wrong

#463 asked in 2021 whether ConfigurationManager should be used at all. The
source answers it:

/**
 * @internal only to be used within Extbase, not part of TYPO3 Core API.
 */
interface ConfigurationManagerInterface extends SingletonInterface

getConfiguration() carries a matching note: "this is a low level method and
only makes sense to be used by Extbase internally". So the API that the
tutorials and Stack Overflow answers linked from #463 all recommend is
explicitly not public API — which is worth saying out loud, because people
are using it.

Checked against typo3/cms-extbase on main (dev-main as 14.3).

Questions

1. What is the supported way for a non-controller class to read
   plugin.tx_myext.settings? Passing the settings in from the controller,
   the frontend.typoscript request attribute, site settings — or is
   ConfigurationManagerInterface tolerated in practice despite the
   annotation?
2. Should the manual state plainly that it is @internal, so readers stop
   copying it from older tutorials?
3. Does the answer differ between frontend and backend context, given the
   warning quoted above?

@maddy2101 Would you be able to take this on, or at least say which of the
options in question 1 is the one we should document?