EZP-23328: Split IO handler / DFS

> [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 also implements native support for:
- legacy DFS cluster IO, storing metadata to ezdfsfile;
- local filesystem IO.

## 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.

`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.

### 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...).

### Legacy DFS Cluster metadata handler
This metadata handler reads & writes to & from the legacy ezdfsfile table. It can be used with a local flysystem adapter, writing to the NFS folder.

A front controller is provided by means of an event listener. It will stream files over HTTP using the Image IOService.

## 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 files or remote files.

It can be used with FS or DFS 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
                binarydata_handler: local

    metadata_handlers:
        flysystem:
            local:
                adapter: local_adapter

    binarydata_handlers:
        flysystem:
            local:
                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.

## TODO
- [ ] Fix usage of getExternalPath in `eZ/Bundle/EzPublishRestBundle/ApiLoader/Factory.php`
- [x] Write BC doc (including removal of `getMetadata`, `getExternalPath` and `getInternalPath`
- [ ] Try a LockAware MetadataHandler, that would lock rows like DFS does
- [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$}
```
Yes, it depends on the registered handlers :/