[TASK] Do not create caches during ext_localconf.php phase

CacheManager has a design problem:
The CacheManager is used to create the core_cache. That core_cache
is used to read the (possibly) cached CacheManager configuration,
which is then used to configure the already-being-used CacheManager.

That means the initialization sequence currently is like:

new CacheManager(!$failsafe) | setInitialCacheConfiguration() |
    loadExtLocalconf() | setFinalCachingFrameworkConfiguration()

Between initial creation of the CacheManager and
setFinalCachingFrameworkConfiguration() the CacheManager is in a limbo
state, as it may already be used to create a cache although the final
configuration (which may be configured in ext_localconf.php) for that
cache has not been set. The final configuration (for that created cache)
will then be ignored, as the cache has already been created.

This is not a theoretical problem, but is actually happening in core
for two caches (introduced due to patches in the v9 development
phase, more on those later).

In v10 we want to change the sequence to the following:

$coreCache = createCoreCache() | loadExtLocalconf |
    new CacheManager(!$failsafe, $cachingConfiguration, $coreCache);

We want to delay CacheManager until ext_localconf.php has been loaded
(maybe also after baseTca loading) in v10.
Therefore GeneralUtility::makeInstance(CacheManager::class) usage in
ext_localconf.php is deprecated now.

Note: The core cache cannot be modified in ext_localconf.php - that was
always the case and wouldn't make sense (as that cache is used to actually
load the cached ext_localconf.php)

Two caches are actually loaded too early during ext_localconf.php loading
currently. We fix these as a drive-by:
 * extbase_reflection: the extbase Object\Container is instanciated in
   EXT:extbase/ext_localconf.php. The Object\Container then instanciates
   the ReflectionService in its constructor which itself creates the
   extbase_reflection using the CacheManager (all of that during
   ext_localconf.php loading).
   This is actually a regression introduced in
   https://review.typo3.org/54381
   We change the Container to load the reflection cache on demand.
 * assets:
   * IconRegistry uses the 'assets' cache and loads cached backend
     icons during object construction.
     This cache was introduced in https://review.typo3.org/c/54020/
     using  the core cache, and was later changed to 'assets' in
     https://review.typo3.org/54061
   * PageRenderer loads cached requireJS configuration from 'assets'

   We inject assetsCache to these services from Bootstrap for now. We'll
   only be able to properly refactor this, when dropping support for
   ext_localconf.php altogether.

We also adapt the ExtensionManagementUtility to retrieve the coreCache
as parameter, instead of statically. Although these methods are marked
@internal, we keep them for 9LTS to not break extensions (using this
regardless of being @internal, e.g. helhum/typo3-console) shortly before
the release.

Change-Id: I22935dae3acb6e8de14fa98a6b88f3477a3ea313
Releases: master
Resolves: #86353
Resolves: #86371
Resolves: #86372
Reviewed-on: https://review.typo3.org/58371


Tested-by: TYPO3com <no-reply@typo3.com>
Reviewed-by: Susanne Moog <susanne.moog@typo3.org>
Tested-by: Susanne Moog <susanne.moog@typo3.org>
Reviewed-by: Frank Naegler <frank.naegler@typo3.org>
Tested-by: Frank Naegler <frank.naegler@typo3.org>