EZP-20948: Added URI handling to IO API

**Review for shared refactoring/Binary fields Value API change proposal**

See https://jira.ez.no/browse/EZP-20948 (Missing support for binary files URI).

This PR does quite a few things:
- replaced `BinaryType\Value->path` with `BinaryType\Value->id` & `BinaryType\Value->uri`
  - `id` is unique at handler level
  - `uri` is the HTTP URI of the objects (see further in the doc)

This allows us to get rid of the `getExternalPath()` and `getInternalPath()` in `ImageStorage`: they were used to get the internal path, at handler level, for the image, since this is what `ezimage` stores in legacy. WIth this change, `ImageStorage` can use the `uri` property, while `BinaryFile` & `MediaFile` can use the `id` property, since this is what they store.

At `IOService` & IOHandlers level, the API is now more clear, with a clear distinction of ids within the various layers. It should make implementation of new IOHandlers easier.

The URI property is meant to be generated by IO Handlers. Legacy & Filesystem (used in tests) will return an URI relative to the document root. Other handlers are free to return any type of URI, like an http one.

## Backward compatibility

### FieldType\BinaryTypes\Value::path removed
This PR changes the properties of FieldType\Image\Value. This may be seen as a BC break, as it will impact REST & Public API code.

Compatibility can be restored by adding `path` to either the Value classes or to `toHash()` and `fromHash()` as an alias to id, both for input and output.

However, since those classes aren't part of the Public API, the BC level expected on those isn't clear.