KernelClient: factor out generic async client from Qt client

before #7108 it was simple for a third-party front-end to recieve message notifications asynchronously from (non-blocking) KernelClient by overriding, or even monkeypatching the `call_handlers` method on the channels like this
```
self.kernel_client.shell_channel.call_handlers = self.on_shell_msg
self.kernel_client.iopub_channel.call_handlers = self.on_iopub_msg
...
```
This is not as simple anymore; now `qt.client` implements the requied logic (a single ioloop thread) but it is tied to the Qt signal/slot mechanism. This PR splits out a generic async kernel client from QtKernelClient, that essentially preserves the behaviour of the old `KernelClient` (execpt that is uses less threads, thanks to #7108).

The only (intended) "semantical" change is that `_check_kernel_info_client` is moved outside `call_handlers` (so that subclasses don't need to care about this), but I don't know the exact purpose this have, so I can't be entirely sure this is handled correctly. 

I'm not sure `AsyncKernelClient` is the best name tho, perhaps `ThreadKernelClient` is more explicit?


And even then, it's only possible to have an issue when there are two listeners on the same message - one on the QtSignal and one on the inner loop, one of which is modifying the message content, which it shouldn't do.