Better API for send_control_message(), or at least some short-term refactoring

There certainly are a lot of TODO HS comments on ClientCirc::send_control_message. As near as I can tell the open questions are:

1. Should it be able to send more than one message?
2. Should the "MsgHandler" be called something else, or have a different API?
3. Instead of a MsgHandler, should this be a stream-oriented API that returns a couple of futures::mpsc::channels that you can use to send and receive control messages?
4. Should we call these "control messages" at all? Is there a better name for them?
5. Should it take a "target hop" argument?

If left to my own devices, I would resolve these questions as follows:

1. We can let it take an IntoIterator<AnyRelayMessage> as an argument.
2. I am okay with the MsgHandler name as it is for now. For an API, perhaps it should have some way to send additional messages on the circuit?
3. I suggest not radically refactoring in this way right now. The current design has implications for making sure that invalid messages of various kinds cause the circuits to close promptly, and that messages are handled in the right order with respect to the messages we have sent. I bet we could keep these properties, but they're
4. We haven't come up with a better name, but we can try. There isn't one in our standard tor vocab.
5. I say "yes". We'll need that for onion services, I think.

@Diziet, you have the strongest opinions here; any thoughts?