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.

I would not make this a LockFactory at all. This should just be a wrapper Directory and override makeLock() to wrap the lock returned by the delegate as DistributorLock. Wrapping LockFactories was completely removed in Lucene's test-framework. Check out, how MockDirWrapper handles this - you jshould just wrap directories and locks. Keep in mind, LockFactories should really always have no state at all and be singletons.