The `ConsoleLayer` builder provides the user with a console layer and
a server, which is used to start the gRPC server.

However, it may be desireable to expose the instrumentation server together
with other services on the same Tonic router. This was requested
explicitly in #428.

Additionally, to add tests which make use of the instrumentation server
(as part of improving test coverage for #450), more flexibility is
needed than what is provided by the current API. Specifically we would
like to connect a client and server via an in memory channel, rather
than a TCP connection.

This change adds an additional method to `console_subscriber::Server`
called `into_parts` which allows the user to access the
`InstrumentServer` directly. A handle which controls the lifetime of the
`Aggregator` is also provided, as the user must ensure that the
aggregator lives at least as long as the instrument server.

To facilitate the addition of functionality which would result in more
"parts" in the future, `into_parts` returns a non-exhaustive struct,
rather than a tuple of parts.

Closes: #428

Co-authored-by: Eliza Weisman <eliza@buoyant.io>

Instead of aborting the aggregator task upon dropping the
`AggregatorHandle`, we now provide an explicit `abort` method. If the
user chooses, they can discard the aggregator handle and while they will
lose the possibility to clean up the aggregator task, they will be
otherwise unaffected.

As discussed in code review, for such a low level api as
`Server::into_parts`, it makes sense to allow the user to spawn the
aggregator where they like, rather than spawning it internally.

Since I couldn't find a way to return and use a `dyn Future` (boxed or
otherwise), the `Aggregator` has been made public with a (async) single
function `run()` which will start it's run loop.