Implement BlendedTermQuery#extractTerms to support highlighing.

some of the highlighters require term extraction to be implemented in
order to work. BlendedTermQuery doesn't implement the trivial extraction.

Closes #5246
Add coming 0.90.12 version to the constants
remove thread local recycler

the thread local recycler requires obtain and recycle to be called on the same thread, while other recyclers do not. Also, it can create heavy recycle usage since it depends on the threads that its being used on. The concurrent / pinned thread base one is by far better than the pure thread local (and is the default) one since it more easily bounds the elements recycled, while still allowing to mix obtain and recycle across threads.

We will end up using the paged recyclers more and more, for example, in our networking output buffer, where obtaining will happen on one thread, while recycling can potentially occur on another thread (the callback thread). Since the limit of binding to a thread of the 2 calls is not really needed, and our best implementation supports going cross threads, there is no real need to impose this restriction.
Remove nanoTime in global cluster randomization in favor of deriving the
seed from the main master seed. Removed shared cluster's seed entirely.

The problem here is that if you don't give cluster's seed then test times
fluctuate oddly, even for a fixed -Dtests.seed=... This shouldn't be the
case -- ideally, the test ran with the same master seed should reproduce
pretty much with the same execution time (and internal logic, obviously).

From the code point of view "global" variables are indeed a problem
because JUnit has no notion of before-suite hooks. And RandomizedRunner
doesn't support context accesses in static class initializers (this is
intentional because there is no way to determine when such initializers
will be executed). A workaround is to move such static global variables to
lazily-initialized methods and invoke them (once) in @BeforeClass hooks.
Refactored TransportIndexReplicationOperationAction to be able to expose the shard id related to a shard failure

The `ShardOperationFailedException` is now created within `TransportIndexReplicationAction` passing in the current shard id as a constructor argument.
Also replaced `AtomicReferenceArray<Object>` with `AtomicReferenceArray<ShardActionResult>`, where `ShardActionResult` wraps the `ShardResponse` or the failure, containing all the needed info.
Minor cleanups.
Class name typo.
Add failures reason to delete by query response

Closes #5093
Expose delete by query shard failures follow-up

- Removed if conditions on index name and shard_id
- Added REST test
[TEST] removed REST test that checks for delete by query shard failures

The clients return an exception in case of failure and not the whole json response containing failures, thus this tests can only work with the Java REST tests runner
[DOCS]: fixed small problem in example json
refactor SimpleQueryParser settings into separate class, add "lenient" option

Fixes #5011
Migrated p/c queries from id cache to field data. Changed p/c queries to use paging data structures (BytesRefHash, BigFloatArray, BigIntArray) instead of hppc maps / sets.
Also removed the id cache.

Closes #4930
Added missing licence header.
Moved AbstractHash, BytesRefHash and LongHash to o.e.common.util
[DOCS] Updated memory considerations for p/c queries and filters.
Upgrade to Lucene 4.7

Closes #5104
Closes #5129
Closes #3757
Expose `filler_token` via ShingleTokenFilterFactory

Lucene 4.7 supports a setter for the `filler_token` that is
inserted if there are gaps in the token stream. This change exposes
this setting.

Closes #4307
Improve `arc` geo-distance accuracy.

Close #5192
Moved es download master url from JDK7 to JDK6