Core: upgrade to current Lucene 5.0.0 snapshot

A few recent lucene changes to fold in:

We've removed IndexWriter.unLock in Lucene, so I also removed "clear
lock on startup" in Elasticsearch.  A couple test cases were missing
engine.close() before opening a new engine.

I exposed the new SerbianNormalizationFilterFactory.

I noticed that we silently use NoLockFactory if you have a typo in
your index.store.fs.fs_lock; I changed this to throw
StoreException instead.  I think it's scary to be lenient
here?

The trickiest change was DistributorDirectory, and how it tracks the
file created by the lock factory.  For the writeFiles boolean, I had
to remove the check that "lockFactory instanceof FSLockFactory"; maybe
we could use reflection to get this, if it's really necessary?  (Do we
really support using NoLockFactory w/ FSDirectory?).  Or maybe instead
we could check if the class name of the lock/factory is NoLock, but
MockDirWrapper wraps in AssertingLock...

I added some harmless "synchronized" to methods (all callers of these
private methods are already sync'd) just to make it clear on quick
look that all access/changes to nameDirMapping are in fact sync'd.

I also fixed ConcurrentMergeSchedulerProvider to disable Lucene's CMS
stalling (override w/ an empty maybeStall method).  We can simplify
things here: remove EnableMergeScheduler, the separate MERGE thread
pool, let IndexWriter launch merges when they are needed (not
separately, once every second), etc., since Lucene won't stall
indexing threads anymore ... I'll open a separate issue for this.

One way to implement this:
Ignore the LockFactory of the inner directories and require the LockFactory to be set on DistributorDirectory itsself (by extending BaseDirectory and taking a external LockFactory on ctor). In that case the Distributor would know the exact type of lock, because it is responsible for locking. The underlying directories would just need no locking at all (NoLockFactory). But this would be a change out of the scope of this issue.

But I like the current impl better. Locking should be the responsibility of the directory that actually holds the lock. This implementation is now implemented the same way like FileSwitchDirectory. FileSwitchDirectory just has the additional "feature" that it delegates the makeLock() call by its file extension, too (and no longer places it in primary dir), see MIGRATE.txt in Lucene.

Please also keep in mind, that the lock file itsself is an implementation detail, so maybe we get another lockFactory in the future that does not create any files at all (e.g., by locking the directory itsself or writing some information to its metadata). So to me it looks wrong to see the lock file as required to be listed in listAll(). Lucene itsself does not depend on that (because lock files are unknown to lucene), Lucene just uses the makeLock() method, nothing more.