Acquire repository lock forcefully (fix #12359).

This PR aims to fix [ticket #12359](http://trac.openmicroscopy.org.uk/ome/ticket/12359). The situation described in the ticket was not possible to reproduce. Hence applying common sense here. The test class ``LegacyRepositoryUnitTest.java`` is now fixed.

To test:
- Verify that ``LegacyRepositoryUnitTest.java`` has no errors (``./build.py -f components/blitz/build.xml test -DTEST=ome/services/repo/test/LegacyRepositoryUnitTest`` - but only if your binary repo is ``/OMERO``),
- Verify that the server starts up,
- Verify that after server shutdown, the ``.lock`` file is deleted from ``/OMERO/ManagedRepository/.omero/repository/<uuid>/``

/cc @dpwrussell
The general explanation is in the description of https://trac.openmicroscopy.org.uk/ome/ticket/12359. In broad terms, @joshmoore mentioned a possibility of the managed repository object disappearing (how? why?) from the scope of the Ice thread. That would cause the server to throw a "No FS!" exception, as the lock on the ``.lock`` file would still be held inside the JVM. Here I wanted to try and obtain a fresh file lock to allow the server to be able to use the managed repository after such situation.

It was impossible for me to reproduce a situation where a stopped or crashed server still in some way holds a lock on the ``.lock`` file... Happy to correct or remove, however you see fit.