Allow explicit specification of the steps Rally is executing for a benchmark

[danielmitterdorfer]

This is an enabler ticket to use Rally in more situations. Currently, we assume a very specific order of steps:

1. Source code is checked out
2. Issue gradle clean, then gradle assemble
3. Copy the resulting ZIP, adapt the config and the log file
4. Launch the benchmark candidate
5. Run benchmark
6. Print command line report

The only "flexibility" so far is the --skip-build flag, which skips the second step allowing to iterate faster. With this ticket, we introduce the concept of a "pipeline", similar to build pipelines. With this new structure we want to enable use cases like:

• Downloading a prebuilt distribution from the official repositories instead of building Elasticsearch from source (changing steps 1 - 3)
• Leverage other tools for provisioning (e.g. Ansible) (changing step 3)
• Just benchmark a prepared Elasticsearch instance that is already running (eliminating steps 1 - 4) although this will not allow us to attach telemetry (or only in a very limited fashion) and we lose effectively all control over the benchmark candidate risking correctness issues.
• etc. etc.

In the scope of this ticket, we will also adapt the command line flags:

• Old: esrally --skip-build (will be gone then)
• New: esrally --pipeline from-sources-skip-build

We'll strive to keep all defaults, so if users just invoke esrally it will still do what they expect (namely: run all the steps above).

We will also overhaul the list subcommand. Currently, there is a bolted-on esrally list-telemetry. In the scope of this ticket, we will generalize the list command to allow:

• esrally list telemetry (behaves similar to the previous esrally list-telemetry)
• esrally list pipelines (prints all available pipelines)
• esrally list tracks (prints all available tracks)

In summary, we provide a uniform list subcommand interface to users.

To be clear, we just introduce the pipeline concept in this ticket but we will not (yet) support the use cases above. We will also not allow users to specify their own pipelines. This does not make sense with the current API and we should defer this decision until the API is much more mature.