Fix EZP-22510: As a developer, I want to directly inject dynamic settings in my services

Before 5.4, if one wanted to implement a service needing siteaccess-aware settings (e.g. language settings),
they needed to inject the whole `ConfigResolver` (`ezpublish.config.resolver`) and get the needed settings from it.

This was not very convenient nor explicit.
Goal of this feature is to allow developers to inject these dynamic settings explicitly from their service definition (yml, xml, annotation...).

Static container parameters follows the `%<parameter_name>%` syntax in Symfony.

Dynamic parameters have the following: `$<parameter_name>[, <namespace>[, <scope>]]$`

Default namespace being `ezsettings`, and default scope being current siteaccess.

For more information, see [ConfigResolver documentation](https://confluence.ez.no/display/EZP/Configuration#Configuration-DynamicconfigurationwiththeConfigResolver).
EZP-22510: Ensure resettable services are reset on config scope change
EZP-22510: Support dynamic settings injection via setters
EZP-22510: Declared ezpublish.config.dynamic_setting.parser service
EZP-22510: Clarified properties names
EZP-22510: Fixed ConfigScopeListenerTest
EZP-22510: Added documentation note on DynamicSettingParser service

[ci skip]
EZP-25510: Fix doc
Fix EZP-23391: As a developer, I want to use dynamic setting with stylesheets/javascripts assetic tags

> https://jira.ez.no/browse/EZP-23391
EZP-23391: Changed the asset factory to handle an array of files
EZP-22510: Fixed a possible bug in ConfigResolverParameterPass

When iterating over definition arguments, the index is considered numeric
when calling replaceArgument.

It seems that this index can be a string (index_$i) when the definition
has been created using a decorator. This removes index_ from the uri if
it is there.
Merge pull request #810 from ezsystems/impl_EZP-22510_dynamicParameters

Fix EZP-22510: As a developer, I want to directly inject dynamic settings in my services
EZP-22510: Added doc on limitations with dynamic settings.
EZP-22400: Added friendsofsymfony/http-cache-bundle dependency
EZP-22400: Added FOSPurgeClient
EZP-22400: Deprecated Multiple/Single purge clients and associated config
EZP-22400: Undeprecate multiple_http and single_http, but considers them as just "http"

"http" purger is now always using FOSPurgeClient and sends a unique BAN request for all locations to purge.
Such BAN requests are supported by Symfony internal reverse proxy, via LocationAwareStore.
EZP-22400: FOSPurgeClient now only supports BAN request
EZP-22400: Make LocalPurgeClient the default one back.
EZP-22400: Implemented a factory to build Varnish proxy client

This makes it possible to merge purge servers defined in eZ SiteAccess aware config with the one defined at FOSHttpCacheBundle levels