EZP-22662: Implement core Public API configuration using Symfony container component

This PR resolves https://jira.ez.no/browse/EZP-22662

* implements Symfony Container configuration of Legacy and Solr storages and changes PAPI to use Symfony Container component
* refactores configuration so that PAPI has its own core configuration that MVC layer uses and builds upon
* handles cached storages as real storages (tagged services) and handles multiple storages from MVC context

###  Legacy and Solr storage configuration in Symfony container

Legacy and Solr storage are now completely configured through service container. This made possible to remove LegacyStorageEngineFactory.

### Move of PAPI core configuration to Core/settings

It should be possible to use Public API as a standalone component, so all core PAPI configuration is moved to `eZ\Publish\Core\settings`.
This configuration is now used by MVC layer as a base to build upon the functionality required by CMS.

Configuration files and container compilation passes are componentized in a way that makes override in MVC layer clean. It also separates storage specific configurations in an obvious way.

### Lazy services

All storages and storage handlers with SPI interface are configured as lazy.
Due to overhead of proxying, fieldtypes, field value converters and external storage handlers and gateway are still lazyloaded as closures.

### Cached storages

Cached storages are now available as tagged services, meaning there is no switch for SPI cache anymore. Instead, different storage should be configured. For now `legacy` and `cached_legacy` are available, `legacy_solr` and `cached_legacy_solr` are available in core PAPI configuration and are for now used in integration tests only.

Due to the implementation specifics of abstract Cache Storage `cached_legacy` depends on `legacy` storage and `cached_legacy_solr` depends on `legacy_solr` storage. Standalone `solr` storage makes no sense and thus does not exist.

Default storage engine is changed from `legacy` to `cached_legacy`.

### Database connection

`LegacyDbHandlerFactory` is transformed into general `StorageConnectionFactory`, now returning Doctrine Connection directly. As each storage now configures its own connection service, in MVC layer this factory is dynamically (compilation pass) aliased for each storage that is found to be configured.

A bug was found in Doctrine ConnectionHandler, where it is not possible to simply pass Doctrine Connection to the ConnectionHandler when SQLite or Postgres is used, since we handle specifics for each these using subclass of ConnectionHandler. Due to the Symfony container enforcing service class, this was solved by adding new static methods to ConnectionHandler: `createConnectionFromDSN` and `createFromConnection`, which are in configuration used as a static factory methods.

### Handling of multiple storage engines

From user perspective nothing changed here. Repositories are configured same as before, with possibility to use `legacy` and `cached_legacy` as a storage by default.

### Symfony container component based PAPI service container

New service container is implemented with caching support, using Symfony container component as internal container.
By default it will try to find `containerBuilder.php` inside configured settings directory.
Old service container is removed.

### Integration tests

All integration tests are adapted to work with new container.
Test YAML configuration files are introduced, making possible to easily override configuration for each test suite.

### Miscellaneous

* `ezpublish.api.storage_engine.legacy.defer_type_update` is removed, deferred handler now needs to be configured as a dependency
* `ezpublish.connection` alias is removed, connection is now configured per storage

### Additional fixes

* UserGroup limitation type was wrongly configured using `UserGroup` instead of `Group` as alias
* Role exception conversion gateway was not used and was missing a method
* Doctrine connection for SQLite and Postgres can't be simply passed to Connection handler because of the specifics handled in `SqliteConnectionHandler` and `PostgresConnectionHandler`. This is reported in https://jira.ez.no/browse/EZP-22522 and is fixed here with new ConnectionHandler methods described above.
* misleading messages for failed assertions in FieldType integration tests

### TODOs

- [x] add more description :)
- [x] implement caching of Symfony container
- [x] remove old container and settings
- [x] configure Solr storage
- [x] test new compiler passes
- [x] look into how to handle cached storage as proper storage (tagged service)
- [x] configuration: sanely handle multiple storages
- [x] lazify stuff
- [x] restore legacyKernel for test usage
- [x] update config.php