multi.jl: simplification/refactor of worker management

Instead of having the ClusterManager keep the configuration and (sometimes) misc info on all its workers, have the workers store the config info specific to themselves, along with a manage() function to do things like interrupt, register, deregister, etc.

Thoughts, gentlemen? I would especially appreciate testing of the SSH bits.

If we like this design, I have a branch of ClusterManagers.jl that fits this design.