[#55141908] Force guest customisation

Ensure that guest customisation is enabled even if the vApp template and
subsequently provisioned VM has it disabled.

This will cause the API to throw a 400 response if it thinks that the
version of VMware Tools on the guest doesn't support customisation. I think
this is more desirable, because it makes it apparent that the VM won't have
the correct hostname or static IP address.
Replace custom power_on method

I don't see any reason for defining this when Fog already has a `#power_on`
method for `server` objects and it has the same response code of 202:

https://github.com/fog/fog/blob/master/lib/fog/vcloud/requests/compute/power_on.rb#L6
[#55141908] Cycle power to identify VMware Tools

There is some problem with our template which causes Guest Customization to
be disabled, both for the template and newly provisioned VMs. Which means
that network and hostname configurations are not applied.

Preceding commit 4e81b43 forces the flag to be turned back on after a
vApp/VM has been provisioned. But it fails with a 400 response because
vCloud doesn't think that the VM has a suitable version (or any install, at
all) of VMware Tools installed.

However we have now produced a template with an OSP version of VMware Tools
that works after a VM has been booted once, then shutdown and the flag
changed. So take advantage of this by doing the same steps during
provisioning.

After booting the VM, and before applying customisations, it waits 90s for
vCloud to populate the `VMWareTools` attribute. When this is present vCloud
has recognised that VMware Tools is present. The VM is then powered off
(caveat in comments) and customisation proceeds.

Tested against SS Platform1 with alphagov/boxgrinder-appliances@60550e5
[#55141908] Replace #power_off with #undeploy

The `#power_off` method leaves the VM in a "Partially Powered Off" state
which causes the Guest Customizations to not be applied. If you look at the
VM properties it will say something to the effect of "Customisations are out
of sync with the guest OS. They will be synchronized the next time the VM is
powered on" (paraphrased)

It seems that `#undeploy` is preferred for correctly shutting down a VM. The
network/hostname settings are then applied without manual intervention. I
believe this will also default to a graceful shutdown instead of pulling the
power.

Despite it's scary name, the documentation seems to confirm that it doesn't
actually delete anything:

http://pubs.vmware.com/vcd-51/index.jsp#operations/POST-UndeployVApp.html
Merge pull request #11 from nosborn/master

Increase create wait time to 3 minutes.
Merge pull request #10 from alphagov/force_customisation

[#55141908] Cycle power to identify VMware Tools
Release version 0.2.3
Merge branch 'master' into vcloud_director

* master:
  Release version 0.2.3
  [#55141908] Replace #power_off with #undeploy
  [#55141908] Cycle power to identify VMware Tools
  Replace custom power_on method
  [#55141908] Force guest customisation