[WIP] Fix EZP-22280: Implement a native image AliasGenerator

> https://jira.ez.no/browse/EZP-22280

This PR implements a native image alias generator, using [Imagine lib](http://imagine.readthedocs.org/en/latest/) with the help of [LiipImagineBundle](https://github.com/liip/LiipImagineBundle/).
However, while interfaces provided by LiipImagineBundle are implemented and services properly exposed, `AliasGenerator` directly uses eZ specific DataLoader and CacheResolver.

## Open questions
0. **Metadata**: currently no metadata is retrieved for each image alias. Best practice is usually to display at least width and height in image html attributes.
  * *Option 1*: Stay as is and don't care about those
  * *Option 2*: Retrieve metadata on the fly for each image alias (potential important performance hit)
  * *Option 3*: Store metadata somewhere (e.g. new table in the DB or Stash).
0. **`LiipImagineBundle` integration**: should we use full mechanism provided by `LiipImagineBundle`? It would allow direct Amazon S3 integration, plus data loader / cache resolver per filter. Drawback would be consistency with our IO repository.
0. **Image aliases removal**: With current behavior, image aliases are being removed one by one. What about removing all aliases for a given filter? 
  * *Option 1*: Change the image alias directory layout, and store by filter (almost no cost).
  * *Option 2*: Store information in the DB, but we would need a unified API for consistency with the Repository API.

## TODO
* [x] Implement LiipImagineBundle interfaces
* [ ] Implement siteaccess aware configuration for filters
* [ ] Implement mechanism to remove image aliases when trashing/deleting content (`SignalSlot` for content repository integration, `ezpEvent` for legacy admin integration)
* [ ] Tests
Imagine lib applies filters directly on blobs. LiipImagineBundle then dumps generated file using this or that cache resolver.