Add and register a comm to register *other* comms

[eddiejessup]

This comm allows a client to send comm-messages to it, containing
data specifying a new comm to register on the kernel. This minimal
comm allows much greater extension of the kernel's behaviour, when
access to the kernel object isn't available.

The comm is registered, but not started, when the kernel is
initialized. A comm-open message can be sent to start it, then
comm-messages sent to register new comms, to perform arbitrary
actions on the kernel side.

[takluyver]

I'm not sure about this. We've discussed previously the idea of a 'comms only kernel', which you could expose to let users play around with widgets without allowing arbitrary code execution. If there's a comm always registered which can be asked to call any importable function, that doesn't really work.

If code in the frontend wants to register a new comm in the kernel - or execute any other arbitrary code - can't it do that with an execute request? We've already got a big avenue for remote code execution.

[eddiejessup]

OK I see your point about the comms-only kernel, sounds sensible to me.

I made this change to cater for cases when registering comms is not done explicitly in a frontend, such as by an intermediary handler between a frontend and a kernel. For example, in my use-case I receive a markdown document with embedded Python code blocks. I want to dynamically update the kernel's interactivity mode depending on options set in the markdown for each code block. To register a comm for this, I realised I'd need to execute some dynamically templated Python code from the handler. This seemed ugly, so I took this approach to try to avoid that.

I hope this makes some kind of sense! If it does, would you recommend just running some templated Python code?