Remove StorageDispatcher to simplify configuration system

Refactors an existing API or subsystem for consistency, performance, modularization, flexibility, third-party integration, etc. May imply an API change. Frequently used during the Code Slush phase of the release cycle.

Since a new StorageDispatcher object for which we don't have a clear purpose was introduced in this issue, #1605324: Configuration system cleanup and rearchitecture, this patch is about simplifying the code by:
- Removing it completely, everything still runs, best proof of that it is not needed at this point, and the code looks much cleaner.
- Simplify building Config objects, since they always need a name, the name should be in the constructor, this one looks quite obvious to me since code is cleaner and saves a few lines.

This should also improve performance and lower memory usage, though I don't have any benchmark, it should be obvious that by creating a Database storage once and reusing it for all the request's config objects, we are saving some logic and a few objects to be created.

The whole point is: if all our use cases can be rewritten without it and still simplifying the code, why is it there?
In addition to that it is making other intents of plugging into the config system more complex, like #1616594: META: Implement multilingual CMI

I was involved in the StorageDispatcher discussion and the use-case is legitimate. I agree with sun here that removing it before we have fully established the use cases it was intended for is premature.

I agree with sun, I'd like to see the use cases and technical requirements outlined and put forward before we decide whether it is worth continuing or not. We talked about whether to include it or not in the rearchitecture issue, and it appeared to me that everyone said it was my call, and I made it so now that it's in lets see where we're at before pulling it right back out again. I remember a lot of sun's potential use-cases being pretty compelling at Barcelona (although I admit that its now been too long for me to remember the specifics.)

However about the discussion, since the thing is already in, I think the most important issue would be to give it some use and see how it looks like.

Really, I'll be having a ton of patches in the queue (for the D8MI thing) and StorageDispatcher is just sitting in the middle of most of them. We really need to know how it is going to work to make any progress here.

Quickly rerolled. The init code from core/lib/Drupal/Core/DependencyInjection/ContainerBuilder.php moved to boostrap.inc's drupal_container() recently, that is why the patch did not apply anymore. I believe this should be back to RTBC as soon as it passes.