EZP-23328: Split IO handlers

> [EZP-23328](http://jira.ez.no/browse/EZP-23328)
> Status: All tests pass, ready for review. See moving TODO at the bottom for open points.

This PR splits the former `eZ\Publish\Core\IO\Handler` into two interfaces: a binarydata handler, and a metadata handler. It comes with a default handler based on Flysystem, an abstract filesystem library.

## Service
The IOService doesn't use an IOHandler anymore, but a binarydata handler (and a metadata handler.

### API changes in IOService
A new method, `loadBinaryFileByUri` is added.

`getMetadata()` is removed. The only metadata handler, ImageSize, isn't needed anymore. Image size is read at creation time, and written to the legacy XML, and read from there later on. This happens in the Legacy Converter.

`getExternalPath()` and `getInternalPath()` are deprecated. The "internal path" is replaced by the URI, obtained from the BinaryFile object. Getting the "external path" is obtained from the internal (the URI) using `loadBinaryFileByUri()`.

## Handlers
### LegacyKernel, InMemory and Filesystem are removed
Filesystem is replaced by Flysystem (see below).
InMemory wasn't used anymore.
LegacyKernel is gone, replaced either by Flysystem (for eZFS) or by the legacy dfs cluster metadata handler (see #1023).

### Flysystem binarydata & metadata handlers
Flysystem, an [abstract filesystem library](http://flysystem.thephpleague.com) provides filesystem access. A default, local adapter is provided that writes to the storage folder.

It can also be used to read/write from/to any adapter supported by flysystem (S3, Dropbox...).

## Prefixing files url / UrlDecorator
The uri of binary files can be customized by the binarymetadata handler, using an UrlDecorator. An AbsolutePrefix decorator is provided, that can be used to reference local or remote files.

It can be used to serve image files from a static server, or from a cloud provider when using Flysystem for cloud.

## Configuration
As many io services as necessary can be created in the ez_io extension. The IO service assigned to a site is siteaccess aware.

This is the default configuration. It uses a `local` service, that reads and writes to the storage folder. It an ezpublish.yml, only the first block would be defined.


```yml
ezpublish:
    system:
        default:
            io:
                metadata_handler: local_metadata_handler
                binarydata_handler: local_binarydata_handler

    metadata_handlers:
        local_metadata_handler:
            flysystem:
                adapter: local_adapter

    binarydata_handlers:
        local_binarydata_handler:
            flysystem:
                adapter: local_adapter

oneup_flysystem:
    adapters:
        local_adapter:
            local:
                directory: $io_root_dir$
```

## IO based tests
API & SPI integration tests now both use a temporary directory as their vardir.
The contents of the `var` directory has been moved next to the fixtures it depends on.

The regular Flysystem handlers are used by tests, while filesystem was used before, and wasn't used by the app. Integration tests should now be much closer from reality.

## Handlers registration
Custom handlers can be created. They require:
- an implementation of either `IOMetadataHandler` or `BinarydataHandler`;
- a base, abstract service configuring the handler(s)
- a factory implementing the `ConfigurationFactory` interface

### The ConfigurationFactory interface
The `ConfigurationFactory` does 3 things:
- give the abstract service name
- add the handler's specific semantic configuration
- customize the initialization of the service used by this handler

See the ones in `EzPublishIOBundle/DependencyInjection/ConfigurationFactory` for examples.

The ConfigurationFactory must then be added to `EzPublishIOExtension` from the handler's bundle, with the first parameter as the alias that will be used for this handler:

```php
class MyHandlerBundle extends Bundle
{
    public function build( ContainerBuilder $container )
    {
        parent::build( $container );
        
        $ioExtension = $container->getExtension( 'ez_io' );
        $ioExtension->addMetadataHandlerFactory(
            'my_handler', new MyHandlerConfigurationFactory() 
        );
    }
}
```

## TODO
- [x] Fix usage of getExternalPath in `eZ/Bundle/EzPublishRestBundle/ApiLoader/Factory.php`
- [x] Write BC doc (including removal of `getMetadata`, `getExternalPath` and `getInternalPath`
- [x] Try a LockAware MetadataHandler, that would lock rows like DFS does (see [EZP-23443](https://jira.ez.no/browse/EZP-23443))
- [x] Check that changes to  mimetype don't break BC. We can't just remove the property right ?
- [ ] Improve bad scope fix (path test). Won't set wrong scope for media files, since they're stored in `original`, like binary files, and can't be told apart by path alone. Might be a follow-up. Possible way would be to figure out which fieldtype the service is running for, since each fieldtype has its own (but again: media and binaryfile both use the same handler, don't they ?)
- [x] Figure out why the io_prefix dynamic parameter is sent to UrlDecorator AbsolutePrefix with the default scope instead of the current scope / siteaccess.
- [x] Fix passing of siteaccess aware parameters to legacy io service
- [x] Rebase on top of #810
- [x] Check siteaccess aware settings (`$io_root_dir$`, `$io_uri_prefix`)
- [x] Implement handlers semantic + container config + siteaccess aware config
in another PR)
- [x] DFS Front controller (event)
- [x] Look into ConfigResolver aware flysystem local adapter
- [x] Write specs file
- [x] Add `BinarydataHandler` and `MetadataHandler` interfaces
- [x] Update IOService to use the split interfaces + test
- [x] Adapt Flysystem BinarydataHandler
- [x] Prefix handling in Flysystem
- [x] LegacyKernel MDH & BDH
- [x] Prefix handling in LegacyKernel H
- [x] Prefix handling in LegacyDFSCluster MDH
- [x] Flysystem BDH + tests
- [x] Create services in eZ/Publish/Core/settings, with an equivalent of the old filesystem
- [x] See how scope must be handled. Applicable scopes: `image`, `mediafile`, `binaryfile`
- [x] Handle getUri/urlDecorator
- [x] Implement getMetadata (which handler ?)
- [x] Handle getInternalPath / getExternalPath... you won' get away by ignoring them.
- [x] Fix unit tests broken while doing the above
- [x] Create IOBundle default services: flysystem BDH+MDH local adapter that writes to the storage dir (var_dir + storage_dir) + dfs service (flysystem BDH + local_dfs_cluster MDH)

## Follow-ups
### Misc
- Legacy dfs cluster database connection via semantic config (siteaccess aware ?). Would avoid the maybe complex metadata_handler configuration part.
- Easier flysystem.filesystem root configuration
- Easier configuration for fieldtype / (fielddefinition ??) configuration. This type to this storage, this other type to that storage. But by fielddefinition... ? :-)

### `ezpublish.io` service tag
- `ezpublish.io` service tag, with an alias, and optionally a prefix, that creates a custom io service of this alias and injects it.

```yaml
services:
    ezpublish.fieldType.ezimage:
        class: %ezpublish.fieldType.ezimage.class%
        parent: ezpublish.fieldType
        tags:
            - {name: ezpublish.fieldType, alias: ezimage}
            - {name: ezpublish.io, alias: ezimage, prefix: $images_storage_dir$}
```

### UrlDecorator config
The URL decorator can only be customized using services definitions.
Make it easy to just set an url decorator at semantic config level.

One use case is simple prefixing with a static host, like `ezpublish.system.default.io.url_prefix: http://static.example.com`.

Another is S3. The static prefixing case works here, but it should technically be automatic: as long as S3 is used as the binarydata handler's adapter, an S3 url decorator should be injected into this binarydata handler.