Use container parameters instead of settings

Objective

1. Given #2241633: Simplify site-specific service overrides, a services.yml file in the site directory is automatically picked up.

2. Various services are environment-configurable via $settings in settings.php (→ Settings); e.g.:

   <?php
   $settings['twig_debug'] = TRUE;
   ?>

   …whereas these are consumed and injected basically like an $options hashmap:

   <?php
   class CoreServiceProvider {
     public function register(ContainerBuilder $container) {
       $container
         ->register('twig', 'Drupal\Core\Template\TwigEnvironment')
         ->addArgument(array(
           'debug'=> Settings::get('twig_debug', FALSE),
         ) + $default_options);
     }
   }
   ?>

3. Various factory services can be customized via $settings in settings.php (→ Settings); e.g.:

   <?php
   $settings['keyvalue_service_state'] = 'keyvalue.database';
   ?>

   …whereas these are consumed by a ContainerAware factory:

   <?php
   class KeyValueFactory {
     public function get($collection) {
       // [simplified for clarity]
       $service_id = Settings::get('keyvalue_service_'. $collection, 'keyvalue.database');
       return $this->container->get($service_id)->get($collection);
     }
   }
   ?>

4. In both cases, Settings actually presents an alien to the code.

5. In addition, each of those $settings in settings.php requires additional documentation to explain that changes to them are only picked up after rebuilding the service container.

Proposed solution

1. Instead of $settings in settings.php, leverage the new services.yml file to specify container parameters:

   parameters:
  twig.config:
    debug: true
    auto_reload: true
  keyvalue.services:
    state: keyvalue.database