We needed a way to specify what IP address and port to use when the
Redis server and Tool Data Sink (really its WSGI server) bind for their
respective services, while also being able to specify what address and
port the Tool Meister(s) should connect to in environments where those
address and ports are different (software-defined-networking, or NAT'd,
or some other reason).

We solve this need by adding a new option, `--orchestrate`, along with
a new `--tool-data-sink` option, and adjust the behaviors a bit.

The new `--orchestrate` option accepts two keywords, `create` and
`existing`, which allow the caller to direct tool-meister-start to
either be responsible for creating the Redis server, Tool Data Sink,
and Tool Meister instances, or use existing instances.  The
`--redis-server` (or the `PBENCH_REDIS_SERVER` environment variable)
and `--tool-data-sink` (or the `PBENCH_TOOL_DATA_SINK` environment
variable) options give the caller the ability to specify the IP/port
combinations to use in either operating case.

When `--orchestrate=existing` is specified, the `--redis-server` and
`--tool-data-sink` options (or environment variables) must be specified.

The format for specifying the IP/ports to use via the `--redis-server`
and `--tool-data-sink` options can be one of the following:

  * `<host ip>:<port>`: used both for listening and connections
  * `<listen host ip>:<port>;<connection host ip>:<port>`: the 1st
    host/port pair is used for listening for connections, the 2nd
    host/port pair is used to specify how to make connections to
    the instances

The defaults are:
  * Redis: bind & connect, `${_pbench_full_hostname}:17001`
    * Also binds to `localhost`
  * TDS:   bind & connect, `${_pbench_full_hostname}:8080`

Prior to this change, `pbench-tool-meister-start` had one very long
`main` method.  This refactoring breaks out the orchestration pieces
required to start the Redis server, Tool Data Sink, and the Tool
Meisters, into their own methods and classes, reducing `main` to
something a bit more reasonable.

As part of this work, a new `BaseServer` abstraction, sub-classed for
the `RedisServer` and `ToolDataSink`, now handles how the Redis server
and Tool Data Sink instance tracking works, either when they are
created by tool-meister-start, or created ahead of time by the caller.