[Deploy] decouple sim_cfg and launcher from deploy

[machshev]

Decouple the Deploy objects a little bit more from the rest of the system.

Python objects are shared by using reference counting, and the object will not be garbage collected until all references are dropped. Best practice is to avoid storing references unless there is a good reason to, the more references that are left around the more likely to encounter memory issues.

The other issue is logical coupling. Objects like sim_cfg and the cli args Namespace object are passed all the way through the whole flow and downstream systems pull out attributes that they want. Which means that any changes in these objects can break any downstream systems, making it really difficult to refactor anything.

This PR improves this a little bit by pulling back some of those references.

• The schedule run results dict is migrated from Mapping[Deploy, str] -> Mapping[str,CompletedJobStatus] - in later refactoring this may be improved further, however this means the results are keyed by the name of the deployment objects and not the Deploy objects themselves.
• Launcher objects were being stored in the Deploy objects as public attributes for a single callback function to use. Instead of doing that, we now pass the launcher object to the callback only when required. With further refactoring we might not even need to do that.
• The Scheduler is passed the Launcher class object and then each Deploy object is asked to create it's own launcher object. From what I can see the only reason is so that it can be stored for the callback. This is now unnecessary so the Launcher objects can be constructed directly.
• The Scheduler.run() method returned a mapping of Deploy objects to status strings. But then the results generation functions were accessing further fields from the Launcher via the Deploy object. Instead of doing this the Scheduler now returns a CompletedJobStatus object that contains all the fields required to begin with.

[rswarbrick]

A couple of small comments (since you're going to have to force-push anyway :-) ). Thanks for working to decouple this a bit: it's definitely going in the right direction!