Provide an internal transport abstraction for client rpcs

[glbrntt]

Motivation:

At the moment the four client calls {Client,Server,Bidirectional}Streaming
and Unary all rely on a base call class. It provides things like the
stream channel setup and a place to hold on to the response part
futures.

It also relies on having two different handler in the stream
channel; one for writing requests and another for responses. There are
two variants for of each of these handlers; unary and streaming.
This meant that there was state more or less all over the place. As an
example, timeouts must be adhered to even if the channel never comes up
yet the scheduled timeout task lived in the response handler(s) since it
needs to be able to fail response part promises.

The base call also makes it difficult to use something other than a
Channel for transport, which might be useful for in-process testing, or
generating client calls where the requests may be recorded and the
responses injected by the caller.

Creating a "gap" between the call and the channel may also lend itself
to interceptors and a lower-level API in the future.

Modifications:

BaseClientCall no longer exists, and each of the four call objects holds
on to a ChannelTransport object. This sits between the call and a
channel. It will buffer writes until it has been 'activated' (by the
underlying channel). It also holds on to the response part promises as
well as the timeout for the RPC. The four channel handlers have been
replaced by a single inbound handler which just forwards events to the
transport.

Some tests were rewritten to not use the deleted code.

Result:

• Code is more maintainable
• More visibility into the call state when something goes wrong (i.e.
  did we have a channel when we timed out?)
• Provides an opportunity to add interceptors/lower level API

[Lukasa]

Suggested change

	/// The `Channel` user to transport messages for this RPC.
	/// The `Channel` used to transport messages for this RPC.

[Lukasa]

Hmm, what's this for?

[glbrntt]

It's a requirement on the ClientCall protocol; I think it was added right at the start as a way to chain sending messages: rpc.newMessageQueue().flatMap { rpc.sendMessage(...) } etc., I don't think we've reconsidered its existence though since it clearly doesn't make a lot of sense!

[Lukasa]

How useful are these promises? Is it more useful for this to be some kind of builder? I'm a little worried about the allocation pattern here.

[glbrntt]

Status is probably the most useful, but you're right, the metadata promises are unlikely to be used nearly as much. I'll update this.

[glbrntt]

then -- must be old!