Adds JcloudsLocation.SKIP_JCLOUDS_SSHING

- Config option to do all ssh’ing in brooklyn code, rather than configuring the jclouds TemplateOptions to setup the user.
- i.e. have jclouds return the VM, before we then execute the ssh commands for user setup/creation.


A few comments/questions/concerns about this PR for the reviewer to think about:
* This change is motivated by testing against VMware's vcloud director. There, guest customization can cause the VM to reboot (potentially several times?). We are not waiting for this to complete, and are instead just waiting for the machine to be ssh'able, so we need to be extra careful about retry of ssh commands. We were seeing non-deterministic failures on retry when trying to just configure jclouds sshj appropriately.
* Is `SKIP_JCLOUDS_SSHING` the right name for the config key? If this becomes the default, then having `USE_JCLOUDS_SSHING_FOR_INIT` might be better?
* There are two ssh commands that are run before we get to the `createUser` code. We may need to be more careful about those? However, the first will retry for 5 minutes, and the second will just log if it fails.
  * `waitForReachable` does `computeService.runScriptOnNode` to wait for that ssh command to succeed (i.e. it uses jclouds, but with the retry being controlled by brooklyn)
  * creation of the `SshMachineLocation` (in `createUser` I think) causes `LocalUsageManager.toMetadataRecord()` to be called, which calls `machine.getOsDetails()`. This does an ssh exec to the machine (if metadata is not available from jclouds) to find out about the arch/distro.
Is the 10-minute timeout *per try*, or overall for all attempts? If something goes wrong, will we be forced to wait 500 minutes before timing out?!