Internal: changed every single index operation to not replace the index within the original request

An anti-pattern that we have in our code, noticeable if you use java API, is that we modify incoming requests by replacing the index or alias with the concrete index. This way not only the original user request has changed, but all following communications that use that request will lose the information on whether the original request was performed against an alias or an index, and its name.

Refactored the following base classes: `TransportShardReplicationOperationAction`, `TransportShardSingleOperationAction`, `TransportSingleCustomOperationAction`, `TransportInstanceSingleOperationAction` and all subclasses by introducing an InternalRequest object that holds the original request plus additional info (e.g. the concrete index). This internal request doesn't get sent over the transport but rebuilt on each node on demand (not different to what currently happens anyway, as concrete index gets re-set on each node). When the request becomes a shard level request, instead of using the only int shardId we serialize the `ShardId` that contains both concrete index name (which might then differ from the original one within the request) and shard id.

Using this pattern we can move get, multi_get, explain, analyze, term_vector, multi_term_vector, index, delete, update, bulk to not replace the index name with the concrete one within the request. The index name within the original request will stay the same.

Made it also clearer within the different transport actions when the index needs to be resolved (user facing requests) and when that's not needed (e.g. shard level request), by exposing `resolveIndex` method. Moved check block methods to parent classes as their content was always the same on every subclass.

Improved existing tests by randomly introducing the use of an alias, and verifying that the responses always contain the concrete index name and not the original one, as that's the expected behaviour.

Added backwards compatibility tests to make sure that the change is applied in a backwards compatible manner.
good point, not sure, the small difference between the different variants is whether concreteIndex is final or not, which depends on when we call concreteIndices in the corresponding transport action. The other matter is visibility...in order to share it we would need to make it public. Shall we do it or not?