Create pre-bootstrap extension mechanism

Does symfony/runtime provide such a mechanism? This issue came to be because I answered this question with a "no". symfony/runtime in my opinion should be used to interact with the ecosystem and I can't wait for the day when we can just add a line or two into composer.json overriding the runtime and bam, Drupal runs as a frankenphp worker. But that's a different issue than the problem at hand, it's not really usable as a pre-bootstrap extension mechanism.

In detail. The runtime itself is overrideable thanks to a composer generated template file. This generated file is then included from your front controller. Once you are inside the runtime, there's no override functionality provided. It gets about half way but it's just not there. If your front controller looks like this:

return function (ApplicationGuesser $applicationGuesser) {
}

then GenericRuntime will reflect this closure, see the type, look for a class named Symfony\Runtime\\'.$type.'Runtime in this case Symfony\Runtime\Drupal\Core\ApplicationGuesserRuntime which then can decide at its leisure to pick an appropriate application guesser. However, this API is currently undocumented so the stability is unknown. More importantly, while this is an extension point, which is commendable this early, there is no functionality to provide a default application guesser and no functionality to override the default. DrupalRuntime::getArgument could, of course, provide this functionality -- but then what is symfony/runtime actually useful for if you need the logic from the composer plugin in this issue to collect the default/override information and you need the minimal logic in BootstrapMap folded into DrupalRuntime as well? Worse, if you want to keep the "canonical" way you will need to pass all six of the overrideable types listed in the issue summary which would look quite ugly IMO, something like

return function (ApplicationGuesser $applicationGuesser, SitePathFinder $sitePathFinder, SettingsInitalizer $settingsInitializer...) {
}

I think this is enough to demonstrate my concerns. Or you could go override the reflection code path in GenericRuntime and just pull all these default/override information from a composer generated file but then again what is the point of using symfony/runtime if you hardwire these six anyways?

Using a container definition sounds like a good idea. Adding new things to DrupalKernel definitely doesn't sound like a good idea. Using the bootstrap container itself is highly problematic anyways because some services depend on the database and the database is not functional before settings is included and so that'd be a bad dx: here's a container but take care what order you retrieve services from it 'cos they might not work.

So perhaps we could create a new include -- much like both approaches on the "less bespoke boot" symfony/runtime did -- which, upon inclusion, gives you a container. The composer plugin would change the definition of this container. That's easy, that's just another array. Makes the DX very nice and familiar. Probably the environment overrides could be a single JSON encoded array which gets deep merged into this definition. This would go a long way towards replacing DrupalKernel for boot because currently the state of bootstrap for eg static::$isEnvironmentInitialized is held by DrupalKernel and we need to put that somewhere, in this case it could go on an EnvironmentBooterFactory or some such.

I am much enlightened. Obviously symfony is the answer to everything. Please disregard this issue. I will not continue working on it.