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.
Print command and stdout/err on error

The stdout and stderr (which are merged) are now read
from the created Process instance if the return code
is not 0.
Silently ignore ObjectNotExistException

If `checkLocation` throws an exception, then
`cleanupUpload` will definitely throw an ONEE
since the proxy no longer exists. Cleaner would
be to null some instance variable, but due to
the possibly multi-threaded nature of the Transfer
object, we're doing something simpler here.
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.
Merge 'origin/dev_5_0' into windows-in-place

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
Merge pull request #2242 from joshmoore/windows-in-place

Use mklink under Windows