Refactor kernel channel classes

The kernel 'channels' system had grown into a horribly tangled thicket of multiple inheritance code, using inheritance for three orthogonal differences: channel kind, blocking vs Qt, and ZMQ vs in-process. This is my attempt to trim it into some kind of clarity before we split the repos up (which will make doing this much harder).

* The shell, iopub and stdin channels are no longer distinguished by different classes; they are all instances of the same class. When used with ZMQ, their socket is created and connected for them, and passed in. The exception is the BlockingInProcessStdInChannel, which remains a separate class for now.
* Heartbeat channels no longer share inheritance with the other kinds of channels, as they're performing a rather different function.
* Channels (from here meaning shell/iopub/stdin) are not threads in any case. For the Qt+ZMQ case for which channels were made threads, there is a new IOLoopThread class, which runs a single ioloop in a thread and handles sending and receiving messages on all three channels.
* The methods to send specific message types (e.g. `execute()` and `inspect()`) have all been moved from the channels to the KernelClient. They were already available on the kernel client by some proxying magic, but now they are actually define on the client class.
* The Qt channels had a bunch of signals emitted when specific message types were received, but the dispatch logic used the `message_received` event, and then looked at the message type again, so all the specific signals were unused. I have therefore removed them to make it more obvious what's going on.

Doing this has allowed me to cut out lots of complex class inheritance and mixins. I briefly thought about trying to leave things in place for backwards compatibility, but I don't think there is any sane way to do that in this case. Hopefully, most consumers deal with the KernelClient class, which is largely unchanged.
On purpose. This class effectively exposes two interfaces:

1. A way to ask 'is the heartbeat currently responding?'
2. A callback to fire if the heartbeat fails.

In the blocking client we only use the first API, so we currently have [a subclass](https://github.com/ipython/ipython/blob/master/IPython/kernel/blocking/channels.py#L76) of this just to override this method with `pass` and disable the second API. This change allows me to get rid of that subclass and use this parent class directly.