Transport: better categorization for transport actions

Our transport relies on action names that tell what we need to do with each message received and sent on any node, together with the content of the request itself.
The action names could use a better categorization and more consistent naming though, the following are the categories introduced with this commit:

- `indices`: for all the apis that execute against indices
  - `admin`: for the apis that allow to perform administration tasks against indices
  - `data`: for the apis that are about data
    - `read`: apis that read data
    - `write`: apis that write data
    - `benchmark`: apis that run benchmarks

- `cluster`: for all the cluster apis
  - `admin`: for the cluster apis that allow to perform administration tasks
  - `monitor`: for the cluster apis that allow to monitor the system

- `internal`: for all the internal actions that are used from node to node but not directly exposed to users

The change is applied in a backwards compatible manner: we keep the mapping old-to-new action name around, and when receiving a message, depending on the version of the node we receive it from, we use the received action name or we convert it to the previous version (old to new if version < 1.4). When sending a message, depending on the version of the node we talk to, we use the updated action or we convert it to the previous version (new to old if version < 1.4).
For the cases where we don't know the version of the node we talk to, namely unicast ping, transport client nodes info and transport client sniff mode (which calls cluster state), we just use a lower bound for the version, thus we will always use the old action name, which can be understood by both old nodes and new nodes.

Added test that enforces known updated categories for transport action names and test that verifies all action names have a pre 1.4 version for bw compatibility

Added backwards compatibility tests for unicast and transport client in sniff mode, the one for the ordinary transport client (that call nodes info) is implicit as it's used all the time in our bw comp tests.
Added also backwards comp test that sends an empty message to any of the registered transport handler exposed by older nodes and verifies that what gets back is not `ActionNotFoundTransportException`, which would mean that there is a problem in the actions mappings.

Added `TestCluster#getClusterName` abstract method and allow to retrieve externalTransportAddress and internalCluster from `CompositeTestCluster`.
(putting the comment here... not sure where else to put it)

would love to see all these mappings extracted to separate class (say `ActionNames`) and keep the service as clean as possible