Initial Core::Vm integration test

Basically a boilerplate:

- set up a vApp+Vm
- quick test to ensure it was created.
- Add some contexts for the methods that require update in the API
Add Vm#update_memory_in_mb integ tests

For increasing and reducing memory

This highlights that Vm#memory returns a string :(
Add Vm#update_name integ test
Add Vm#vapp_name integ test
Add Vm#update_cpu_count integ tests

Decrease and increase CPU count. Like Vm#memory, this highlights that Vm#cpu
returns a string :(
Add Vm#update_metadata integ tests

Test that metadata updates preserve existing metadata.

Add a test to highlight that Vm#update_metadata also updates parent vApp metadata.
Add Vm#add_extra_disks integration tests

This also adds a helper function to get *just* the disks returned by
(Model) vm.disks -- it returns the disk controllers (SCSI+ID) too, which
we can filter out by matching on name =~ /^Hard Disk/
Add Vm#configure_network_interfaces integ tests

Test that we can create single and dual nic systems.

This highlights that Fog is misbehaving wrt the vcloud_attributes
section for network cards -- ensure_list! is missing, so we get a
Hash if there is one NIC, an Array if there are >1.

On testing against a second provider, it was noticed that
the :NetworkConnection section returned by the API via Fog is
not ordered as per the insertion order.

Hence, add a helper (sort_nics_based_on_network_connection_index) to sort the
returned array based on the :NetworkConnectionIndex parameter, which then allows
us to test each returned hash in respect of the order we used to insert them.
Skip Vm#configure_guest_customization_section tests

Vm#configure_guest_customization_section contains and calls a lot of
code that handles the 'preamble script' generation, including
reading this from an external file.

This work is better done in Vcloud::Launch::VmOrchestrator, with
an interpolated preamble passed to core as data.

Leaving this test alone for now until we decide what to do, there
are tests in alphagov/vcloud-launcher for this already, so there is
no major reason to re-implement them here right now.
Add Vm#update_storage_profile integ test

If storage profiles are available, switch the Vm from the default
storage profile to a new storage profile.

Allow for marking the test as pending if storage profiles are not
available, by setting the new storage profile to be the same as
the default one.
Remove unneccessary instance vars in Vm test
Simplify :NetworkConnection sort helper
Clarify purpose of cpu count check

The reason to check the initial_cpu_count != new_cpu_count (=1) is to
ensure that we are not effectively doing a no-op in this test. We rely
on the previous test increasing the cpu count to be >1, so this expectation
is really confirming that that has occured.
Improve "sanity check" assertation for CPU count

The previous test should ensure that our CPU count is >1, and hence
that we can test that decreasing it to 1 is ok in this test.

This assertation ensures that though, just in case the test ordering
changes or similar.

Re-write it to better describe this.
Improve Vm#update_storage_profile test

* Clarify the pending() case, that there is no point running the test if there is only one SP

* Move the fixture-state assertation to before the main test code
Merge pull request #48 from alphagov/70499718_vm_integ_tests

[#70499718] Core::Vm integration tests