Nanny proxies control channel, so it can intercept control messages and handle those

• add Client.send_signal for signaling engines (closes Add registration information to launchers #475)
• notify Hub immediately on process exit instead of waiting for heart failure, dramatically improving responsiveness to engine death (closes notify Hub of engine stop from launchers #491)
• exit Engine on any error during completion of registration
• consolidate _send_control_request for control-channel requests
• fix some mixed str/bytes uuid/identity logic in the Hub (related to client().shutdown() gives errors with KeyError: None and OSError: [WinError 10038] on the console #364)
• capture and report subprocess output via files (closes Deal with subprocess output without tornado #484)

Signaling engines directly solves two problems with signaling via e.g. mpiexec and the Cluster API:

1. subsets of engines can be addressed, useful for interrupting a single task
2. different mpiexec implementations may not handle important signals, such as SIGINT which openmpi will forward exactly once before forcibly shutting down engines

In the future, this could also enable abort_request to trigger an interrupt if the to-be-aborted message happens to be processing at the moment. The nanny could subscribe to the IOPub channel to watch status messages to determine what task is currently processing