Use mklink under Windows

In order to support in-place importing on Windows, mklink
rather than ln must be used. Rather than create new commands
like `--transfer=mklink`, the same flags (`ln` and `ln_s`)
are being used.
Fixes from jh713@cam.ac.uk

 * cmd /c is needed to call mklink from Java
 * Arguments need reversing.
Close file handle before attempting delete

@bpindelski showed that on Windows the UUID-containing
file created by checkLocation was not being properly
deleted during import. This change closes the RawFileStore
and then re-opens in order to allow in-place import under
Windows.
Remove ManagedRawFileStoreI in favor of callbacks

ManagedRawFileStoreI was not being used which meant that
closeCalled was never invoked and therefore the proxies
in `ManagedImportProcessI.uploaders` were never cleaned.
This led to `ObjectNotExistException` being thrown on a
second loading of `proc.getUploader(i)`. Rather than add
logic to create the correct subclass of RepoRawFileStoreI,
a callback interface has been added which can be used for
any implementation.

Conflicts:
	components/blitz/src/ome/services/blitz/repo/RepoRawFileStoreI.java
Add 'omero.import.active_close' system property

The primary blocker for this PR as a feature for 5.0.3
was that it broke compatibility with 5.0.2 servers and
earlier. Now the active closing functionality which is
needed for in-place import on Windows is *disabled* by
default, and needs to be activated via:

```
JAVA_OPTS=-Domero.import.active_close=true bin/omero...
```
Fix typo
Clarify checkLocations's error conditions

In order to prevent confusing messages after a
`FileUtils.deleteQuietly()`, we actively throw
an exception for all the in-place import types.
Improve messages on in-place failure conditions
Make active_close on by default
Merge pull request #2795 from joshmoore/rebased/develop/windows-in-place

Use mklink under Windows (rebased onto develop)