The cluster API in #463 has a challenge in that the Cluster only has a handle on engine 'sets' whereas in practice signalling/etc. will often want to target individual engines.

Two ways to address this:

1. to record additional information in engine registration (for example engine set id, hostname, pid) so that EngineSetLaunchers can signal individual children.
2. to implement signalling only via standard requests to a subprocess. Unlike a full KernelNanny, this would be a single process that does nothing more than send signals. It solves the parent-child problem that nanny processes with full restart capabilities have with e.g. MPI where the 'true' worker must be the parent.

Disadvantage of the signaller: it's another scheduler, port, process, etc. to manage

Advantage of the signaller: it's easy to target individual engines and easily works for all Launchers.