MODE-2302 Changed some of the logic behind the interaction of the repository and the binary stores

Some of the significant changes include:
* when a binary value is created via the value factory, it is stored in the `unused` state.
only after a transaction has been successfully committed, should the state of any involved binaries be updated. For binaries which are now referenced, they are marked as `used`. Since this has to work regardless of the transaction type, transaction synchronizers were used
* binary updates are made synchronously with the same thread that commits the transaction. Using the above mentioned approach guarantees that.
* because there are cases when the `InputStream` of a binary needs to be accessed prior to transaction commit (e.g. pre-computing the mime-type for `mix:mimeType`), a `BinaryStore` needs to always be able to provide this stream regardless of whether the binary is used or unsued and __must not change the state of the binary when doing so__.
* unlike the other binary stores, the `FileSystemBinaryStore` up until now was unique in that it physically moved binaries on disk to reflect the used / unused states (using a trash directory). All the other binary stores merely set a flag & timestamp to reflect these state changes. Therefore, the `FileSystemBinaryStore`'s implementation was changed so that binary values are always stored (and never moved) into the same location. When a binary value becomes unused, we simply write out a new, empty file into the trash area which will have the name the SHA-1 of the binary (in effect the binary key). The presence/absence of this file indicates that a binary is used or unused. The cleaning up process will look at the files in the trash area and will only process those which meet the expiry criteria.