[meta] DrupalKernel has too many responsibilities

The DrupalKernel currently has too many responsibilities, and has many qualities of a "god class".
Maybe the Kernel already is too big in Symfony, but it certainly is in Drupal.

There is a number of issues that deal with DrupalKernel refactoring, but they do not really name this problem, and they do not provide a big picture.

The responsibilities will change with issues like 📌 Refactor bootstrap to better utilize the kernel Fixed and #2021959: Refactor module handling responsibilities out of DrupalKernel → . It is also likely to grow further as we split up the procedural files.
Here is a list of responsibilities that DrupalKernel combined from different versions:

Bootstrap / shutdown:
- bootEnvironment() (#2016629)
- initializeRequestGlobals() (#2016629)
- (#2016629)
- boot()
- shutdown(), terminate()

Site management:
- findSitePath()
- manage site directory
- initialization of site config

Site config management:
- (#2016629)
- getConfigStorage() (#2016629)

Request handling:
- preHandle() (#2016629)
- (#2016629)
- handle()
- ( 📌 clean-up outdated mentions of prepareLegacyRequest Active )

Container management:
- service provider management
- service provider discovery
- container initialization
- container dumping
- service persistance

Module management:
- moduleData()
- module update
- module namespaces for the container
- module namespaces registration in the class loader
(While #2021959 proposes to moves most of this into the module handler, I think that could also be split up further)

This is too much for one class to handle. Seriously.
The term "Kernel" itself already suggests that it is going to have too many responsibilities..
(I could go on about how small a class should be for my taste, but I would prefer to leave that to IRC or other places)

So, what about the Symfony Kernel?
DrupalKernel does not have much in common with the symfony kernel anymore, so who cares.
But as a comparison, here are the responsibilities of abstract class \Symfony\Component\HttpKernel\Kernel:
- boot, terminate, shutdown
- request handling
- locateResource()
- bundle management
- container managment
- stripComments() (ouch, this one seems totally out of place)

This is already too much for my taste. But the implementation of these aspects look a lot simpler in Symfony. I assume it is ok, assuming that the average developer won't spend too much time debugging this class.

In Drupal, the Kernel is much bigger, it is intertwined with an ugly environment full of legacy global state, and there are a lot more unknowns and runtime dynamics.

Proposed resolution:

Slice it up, step by step, into components such as ContainerManager, ServiceProviderManager, ServiceProviderDiscovery, RequestHandler, SitePathFinder, etc.
There does not even need to be a DrupalKernel class at all, if all the tasks go into separate components.

To let these components play together, I would personally favor a solution like #2272129: [meta] Introduce a low-level DIC to organize low-level services → , but I am open to other ideas, and I would like to keep these two issues separate.

Another solution would be to keep the DrupalKernel class, but only use it as a "hub" to get to dedicated separate components.