Allow dumping of the container during the installer

Problem/Motivation

The UI installer rebuilds the dependency container on every request and sometimes more than once during a request when modules or themes are installed.

For tests and probably the CLI, this is fine, because there is only one 'request' and then the rest of the install happens inside it. For the UI installer, there are pages like the site settings form and translation import that don't trigger a container rebuild, and these are unnecessarily slow. A container rebuild can easily take hundreds of milliseconds.

Steps to reproduce

Proposed resolution

• Allow dumping only once base_system_verified is TRUE (the prod-env phase, where nearly all requests happen: module install batches, recipes, translation import). The early installer may have no database and keeps compiling per request, so the settings-form/requirements pages are not covered by this.
• InstallerKernel::getContainerCacheKey() gets an :installer suffix so the dumped installer container (with its service overrides) can never be served to the installed site.
• install_drupal() deletes the dumped installer container via invalidateContainer() once installation_finished is set, after all tasks.

Three things had to be fixed to make dumping possible:

1. NormalInstallerServiceProvider passes new Time() as a cache_factory argument — the dump throws "Unable to dump a service container if a parameter is an object". Fixed with new Reference('datetime.time').
2. The same provider removes InlineServiceDefinitionsPass, RemoveUnusedDefinitionsPass, AnalyzeServiceReferencesPass and ReplaceAliasByActualDefinitionPass — safe only while never dumping; the dumped container otherwise breaks on reload with unresolved aliases/private services. Now conditional on the dumping phase.
3. InstallerKernel::initializeContainer() forces containerNeedsRebuild = TRUE on every fresh boot, bypassing the cached-container read — reworked so a fresh boot consults the dump, keeping the in-request memoization and changed-extensions rebuild.

Performance results

All results were on a macOS host, DDEV v1.25.3 (Docker/Rancher Desktop), all executed inside the DDEV web container. Drupal CMS 2.x with core 11.4.5 with MariaDB. Core was main at 7d8143e6 vs the MR commit at 86d12f92 with PHP 8.5.7's built-in server with SQLite. Instrumentation was one temporary probe in DrupalKernel::initializeContainer(). Run with PHP submitting forms immediately (not through browser, so rendering, JS, etc. did not matter).

Ran 3 runs each of the before/after scenarios and averaged with variance included in the table.

Drupal CMS (Blank template) — Apache/MariaDB via DDEV, core 11.4.5 + adapted patch

Core standard profile — actual main (12.0-dev) vs MR commit 86d12f92, PHP 8.5/SQLite

Variance in boots from dump are because the installer bundles batch requests in 1s chunks, so if the run happened to fit more into that, there would be less boots.

Remaining tasks

Review! Test!

User interface changes

None.

Introduced terminology

None.

API changes

None.

Data model changes

None.

Release notes snippet

The late installer now dumps the container to database once that is available, which results a roughly 10% server side speed improvement for foreign language Drupal core installations. Drupal CMS gets even bigger gains with roughly 10% server side speed improvement on English installs and 20% for foreign language.

LLM disclosure

LLM was used to build and measure this fix. The change is really small though and should be independently verified :)