EZP-20948: Added uri property to BinaryBase\Value

*Review for shared refactoring/ API change proposal*

See https://jira.ez.no/browse/EZP-20948 (Missing support for binary files URI).

It is an incorrect version of a good solution. It probably needs to be refactored a bit, but it will work fine in the current state.

Ideally, we would handle this in a semantically correct way by distinguishing the URI from the path (currently used as URI) in `IOService`, `IOHandler` & `BinaryFile`. The path is in fact mostly an identifier, so maybe we should instead:
- rename `(SPI)BinaryFile::path` to `(SPI)BinaryFile::identifier`
- add an URI property, that is obtained from the handler, and exposed by the IOService

This would maybe let us remove getExternalPath & getInternalPath, currently exposed by IOService due to the different image & files handling in terms of external storage.

IOHandlers would receive a path they can handle (e.g. storage/original/application/fd1fa470b633f668fbedb3a19bac5142.pdf), and would according to their business logic build the full URI. For Legacy & FileSystem handlers, an absolute URI is returned. Other handlers could return another HTTP URI, to a cloud service or a different server.