Dynamic configuration handling

This PR introduces a mechanism to resolve **dynamic configuration**, depending on a scope.

Available scopes are (in order of check) :
1. *global*
2. SiteAccess
3. *default*

It gives the opportunity to define settings for a given siteaccess for instance, like the legacy INI override system.

The mechanism is not limited to eZ Publish internal settings (aka ***ezsettings* namespace**) and is applicable for specific needs (bundle related, project related...).

## eZ Publish 5 settings
Considering the following configuration:

```yaml
parameters:
    # default settings, empty
    ezsettings.default.location_view: {}

    # Settings for ezdemo_site siteaccess scope
    ezsettings.ezdemo_site.location_view:
        full:
            smallFolder:
                template: eZDemoBundle:full:small_folder.html.twig
                match:
                    Identifier\ContentType: [small_folder]
                    Identifier\ParentContentType: [landing_page, frontpage]
```

You can use the following code within a controller:

```php
<?php
// Inside a controller

// The following will resolve ezsettings.<siteaccessName>.location_view
// In the case of ezdemo_site, will return the configured hash above. 
// Otherwise it will return the value for ezsettings.default.location_view (empty hash)
$locationViewSetting = $this->container->get( 'ezpublish.config.resolver.core' )->getParameter( 'location_view' );

// Note that the same apply for hasParameter()
```

> Note: that if a `ezsettings.global.location_view` was defined, it would have been selected instead of `ezsettings.ezdemo_site.location_view`.

A second parameter can be added to `getParameter()` method, the *namespace* (defaults to **ezsettings**).

A third parameter can also be added, the **scope** which will override the *relative scope* (i.e. **siteaccess** name in our case).
It makes it possible to fetch a setting from a different siteaccess than the current one.

This can apply to **any** setting.

## Legacy settings
A **LegacyConfigResolver** has also been implemented and can be used the following way:

```php
<?php
// Inside a controller

$legacyResolver = $this->container->get( 'ezpublish_legacy.config.resolver' );
// Get [DebugSettings].DebugOutput from site.ini
$debugOutput = $legacyResolver->getParameter( 'DebugSettings.DebugOutput' );
// Get [ImageMagick].ExecutablePath from image.ini
$imageMagickPath = $legacyResolver->getParameter( 'ImageMagick.ExecutablePath', 'image' );
// Get [DatabaseSettings].Database from site.ini, for ezdemo_site_admin siteaccess
$databaseName = $legacyResolver->getParameter( 'DatabaseSettings.Database', 'site', 'ezdemo_site_admin' );

// Note that the examples above are also applicable for hasParameter().
```

## Chain resolver
A chain resolver has also been introduced and, as its name hints it, allow to chain several configuration resolver.
By default, *Core* and *Legacy* config resolvers are chained with the following priorities:

1. **Core** (priority 200)
2. **Legacy** (priority -255)

A typical usecase is migration from eZ Publish 4.x extensions to version 5.

### Example
Let's take [SQLIImport](https://github.com/lolautruche/sqliimport) as an example.

Considering your *eZ Publish 5* application depends somehow on its configuration. As the extension has not been migrated yet, you would use the legacy resolver to get **RobotUserID** from **[sqliimport.ini](https://github.com/lolautruche/SQLIImport/blob/master/settings/sqliimport.ini)**:

```php
<?php
// Inside a controller

$legacyResolver = $this->container->get( 'ezpublish_legacy.config.resolver' );
$robotUserId = $legacyResolver->getParameter( 'ImportSettings.RobotUserID', 'sqliimport' );
```

This approach will work but the problem is that this way, you couple your application to the legacy bundle (which will have a limited lifetime).

A better approach would be to use the chain resolver:

```php
<?php
// Inside a controller

$robotUserId = $this->getConfigResolver()->getParameter( 'ImportSettings.RobotUserID', 'sqliimport' );
```

This way, the config resolver will first check if a `sqliimport.<currentSiteaccess>.ImportSettings.RobotUserID` parameter key exists. If yes, it will simply return its value. If not it will get the configuration from the legacy resolver.
So basically, when **SQLIImport** is ready for eZ Publish 5, only the new setting will be used.