cloque boshdirector:inception:provision should resurrect "missing" microBOSH

This extends the `boshdirector:inception:provision` command to detects when existing microBOSH instance is missing, and resurrects it launching new microBOSH and then attaching old microBOSH's disk to it.

A resurrection looks like the following:

```
$ cloque boshdirector:inception:provision ami-7e06a009 
> finding inception instance...found
  > instance-id -> i-41e0b101
> deploying...
  > Existing microBOSH instance i-5c4e1e1c missing.  Launching new microBOSH and then attaching old microBOSH's disk to it...
  > uploading "empty" bosh-deployments.yml to prevent attempting to delete old microBOSH...
building file list ... 
1 file to consider
bosh-deployments.yml.resurrect
         139 100%    0.00kB/s    0:00:00 (xfer#1, to-check=0/1)

sent 265 bytes  received 54 bytes  91.14 bytes/sec
total size is 139  speedup is 0.44
  > deploying microBOSH...
    > Using AMI: ami-7e06a009
Deployment set to '/home/ubuntu/cloque/self/bosh/bosh.yml'
  Started deploy micro bosh
  Started deploy micro bosh > Using existing stemcell. Done (00:00:00)
  Started deploy micro bosh > Creating VM from ami-7e06a009. Done (00:02:10)
  Started deploy micro bosh > Waiting for the agent. Done (00:01:32)
  Started deploy micro bosh > Updating persistent disk
  Started deploy micro bosh > Create disk. Done (00:00:03)
  Started deploy micro bosh > Mount disk. Done (00:00:08)
     Done deploy micro bosh > Updating persistent disk (00:00:18)
  Started deploy micro bosh > Fetching apply spec. Done (00:00:00)
  Started deploy micro bosh > Stopping agent services. Done (00:00:02)
  Started deploy micro bosh > Applying micro BOSH spec. Done (00:00:25)
  Started deploy micro bosh > Starting agent services. Done (00:00:01)
  Started deploy micro bosh > Waiting for the director. Done (00:00:16)
     Done deploy micro bosh (00:04:44)
Deployed `bosh/bosh.yml' to `Unknown Director', took 00:04:44 to complete
Connection to 10.101.0.6 closed.
> attaching old microBOSH persistent disk to new microBOSH...
  > unmounting new disk...Connection to 10.101.0.6 closed.
{"agent_task_id"=>"6b47ed39-a08b-4c76-7bca-aefb5f90c3be", "state"=>"running"}
{"agent_task_id"=>"c3435284-9eaa-46f8-4325-45f77c87a5bf", "state"=>"running"}
Connection to 10.101.0.6 closed.
new disk: vol-53b6fb54 unmounted.
Connection to 10.101.0.6 closed.
  > Detach new disk vol-53b6fb54 and attach old disk vol-ec2568eb to instance: i-56792a16....done.
  > Changing disk id reference in (microBOSH):/var/vcap/bosh/settings.json
  > When prompted, [sudo] password for vcap is: c1oudc0w
Connection to 10.101.0.6 closed.
[sudo] password for vcap: 
Connection to 10.101.16.8 closed.
  > Changing disk id reference in  ~/cloque/self/bosh-deployments.yml
Connection to 10.101.0.6 closed.
  > Restarting microBOSH
"started"
Connection to 10.101.0.6 closed.
  > Deleting disk: vol-53b6fb54
> Old microBOSH resurrected!...
> fetching updated bosh-deployments.yml...
receiving file list ... 
1 file to consider
bosh-deployments.yml
         967 100%  944.34kB/s    0:00:00 (xfer#1, to-check=0/1)

sent 50 bytes  received 533 bytes  166.57 bytes/sec
total size is 967  speedup is 1.66
> tagging...done
```
I consider `-o StrictHostKeyChecking=no` a bad practice for security. Can we eliminate it, or, at best, make it an input option.