supervisor.exec_config refactor - no tests (review)

`supervisor.execute_launch_config` returned `Deferred` that fired back with job id and completion deferred. The job id was used by `_Job`. Now, it only returns completion and job id knowledge moved to `_Job`. This way code is simpler. This is based on discussion in https://github.com/rackerlabs/otter/pull/646#discussion-diff-13937435. Unfortunately, most of the discussion happened offline. 
Non-blocking - this may not be a great idea:  @glyph had mentioned in that IRL conversation that if this were generated in the `__init__`, it might be less confusing because the Job wouldn't have two states (one where it has a job ID and one where it doesn't).

I was also thinking that perhaps if in the `__init__`, a blank `Deferred` were created that had as its callback calling execute_config, and building the rest of the callback chain.  It'd get callbacked in `start`, which would actually kick off the job.

That way, the `Deferred` is always present as soon as the Job is created, and is available for introspection.  Also, it can be added to the `DeferredPool` before it's callbacked (kicking off the actual job process), which makes it very clear that it will be removed from the job pool only after everything is done.