Improve FileLocking based on Java 1.6 [LUCENE-3266]

Snippet from NativeFSLockFactory:

```
/*
* The javadocs for FileChannel state that you should have
* a single instance of a FileChannel (per JVM) for all
* locking against a given file (locks are tracked per
* FileChannel instance in Java 1.4/1.5). Even using the same
* FileChannel instance is not completely thread-safe with Java
* 1.4/1.5 though. To work around this, we have a single (static)
* HashSet that contains the file paths of all currently
* locked locks. This protects against possible cases
* where different Directory instances in one JVM (each
* with their own NativeFSLockFactory instance) have set
* the same lock dir and lock prefix. However, this will not
* work when LockFactorys are created by different
* classloaders (eg multiple webapps).
*
* TODO: Java 1.6 tracks system wide locks in a thread safe manner
* (same FileChannel instance or not), so we may want to
* change this when Lucene moves to Java 1.6.
*/
```

since we are on 1.6 we should improve this if possible.

---
Migrated from [LUCENE-3266](https://issues.apache.org/jira/browse/LUCENE-3266) by Simon Willnauer (@s1monw), updated May 09 2016
Linked issues:
- #4312

Start by reading the NativeFSLockFactory code and the linked issue #4312. Compare its current locking workaround with the Java 1.6 FileChannel behavior described in the issue, then identify the affected locking paths and any existing tests. Done should mean the implementation takes advantage of Java 1.6 while preserving correct locking across Directory instances.

Written by the indexing model from the issue text.