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.

Is it a problem if we just track a non-existing file? To me this looks like this is already broken for NativeFSLockFactory, because this one may reuse already created lock files (the existence of lock file does not mean its locked). So we can just record here "there may be a lock file to track".