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
Enable trace logging for RandomExceptionCircuitBreakerTests.testBreakerWithRandomExceptions
Add RamUsageEstimator assertion to ElasticsearchIntegrationTest
estimator#afterLoad should be invoked once only per reader.

It was being invoked once per reader and parent type combination resulting in more memory being reported to the circuit breaker than actually being used in field data.
Add tracking of allocated arrays.

The BigArrays utility class is useful to generate arrays of various sizes: when
small, arrays will be allocated directly on the heap while larger arrays are
going to be paged and to recycle pages through PageCacheRecycler. We already
have tracking for pages but this is not triggered very often since it only
happens on large amounts of data while our tests work on small amounts of data
in order to be fast.

Tracking arrays directly helps make sure that we never forget to release them.

This pull request also improves testing by:

 - putting random content in the arrays upon release: this makes sure that
   consumers don't use these arrays anymore when they are released as their
   content may be subject to use for another purpose since pages are recycled

 - putting random content in the arrays upon creation and resize when
   `clearOnResize` is `false`.

The major difference with `master` is that the `BigArrays` class is now
instanciable, injected via Guice and usually available through the
`SearchContext`. This way, it can be mocked for tests.