Add support for addLocalChild

[hyperthunk]

As per https://github.com/haskell-distributed/distributed-process-registry/blob/master/src/Control/Distributed/Process/Registry.hs, we can pass unserialisable thunks to a supervisor on the same local node, by creating a binary shim to hold the data, and creating a binary instance that simply errors on read and write.

Since the Unsafe module deliberately avoids forcing evaluation of messages, this enables us to safely pass a Process () to a local supervisor, for the purposes of adding it after initialisation.

There are some issues to be observed about this approach...

Firstly, if we wish to add children in this fashion, we might not want to support putting them in the initialisation config for the supervisor. Supporting that notion would make the init config non-serialisable.

We also need to consider whether refactoring the whole code base for this feature is worth it. Perhaps the simplest option that occurs to me, would be to store unclosured child start procs in a map, against the child keys, and when adding a local child, to ignore the closure field and just add the passed proc. So long as code which usually accesses the closure (i.e. The start/restart routines) always checks the map first, this should work fine, with minimal impact.

It could be useful to add an alternate startSup API, that takes LocalChildSpec records instead of the serialisable ones, which should allow for library users to clearly distinguish between supervisors that can be used locally and those which may be deployed to remote nodes. This would get around the issue of having non-serialisable init config.

An interesting issue here is that of nested supervision trees. If a local child spec is for a supervisor, that local child init could indeed contain non-serialisable local child specs, or regular specs.

This change would be incompatible with remote supervision groups, like those that rabbitmq uses to handle load balancing process groups. It would not prevent ordinary supervisor configurationa from being used in those kind of scenarios though...