Basic Core::Vapp integration test

Instantiates a vApp test fixture, and confirms that it was created successfully.
Add integration tests of vApp GET methods

Vapp#id and Vapp#name really just confirm that the fixture vApp is as
expected.

Vapp#vdc_id uses a reasonable amount of logic to get the vApp vDC from
the API Link references - definitely worth having an integration test for this.
Add Vapp.get_by_name integration tests

Confirms that we can retrieve our known-instantiated test vApp.

Confirm that a RuntimeError is raised if the named vApp is not found.
Add Vapp.instantiate passing integ tests

This confirms the behaviour that we can instantiate vAppTemplates
as vApps with zero, one or two 'bridged networks'.

Theoretically we could test more, but we do not have any user need
for >2 networks as yet.

NB: Adjusted the use of the test_data hash to reduce the need for
instance variables.
Add a variable to explain magic value
Add Vapp.instantiate failure-case tests

Document behaviour when bad input is given to the
Vapp.instantiate method.
Add #network test; account for placeholder network

The vCloud API returns a weird 'none' vAppNetwork in the output of
Vapp#networks. I've documented this in #72073214, but for the record
it appears that the output of
`vcloud_attributes[:'ovf:NetworkSection'][:'ovf:Network']` always contains
a network called 'none', detailed as a 'placeholder':

````
  :ovf_name => "none",
  :"ovf:Description" => "This is a special place-holder used for disconnected network interfaces."
````

This appears regardless -- if there are actual vAppNetworks defined, it will still appear.

I've added a helper method -- `sanitize_network_output` -- prevent this behaviour from
muddying each test on the number of networks expected.
Add 'bogus networks' case for Vapp#instantiate

If networks are specified to Vapp#instantiate that are not present
in the target organization, the #instantiate call will succeed, simply
skipping the bogus networks.

This is arguably a bug, that we should instead raise an error.

I have logged #70363690 previously to fix this, but it is worth
documenting the behaviour in the tests.
Add Vapp#power_on integ test

In addition, add support for deleting powered up vApps in IntegrationHelper.delete_vapps
Merge branch 'master' into 70499730_vapp_integration_tests
Use "describe" for method names, not "context"
Explain logic in sanitize_networks_output
Replace methadone with optparse and tests

This is essentially the same as alphagov/vcloud-edge_gateway#70. The
executable has been rewritten to use plain OptionParser and unit tested.

With the difference that exceptions are caught to prevent the stacktrace
being leaked to the CLI, because there's no validation of "types" until you
hit the API, and the stacktrace you get back through Core/Fog/Excon is
exceptionally long.

Aruba/Cucumber has been removed because we no longer need this to
superficially test the command line interface.
Add allocation_mode to vm network configuration
Merge pull request #67 from alphagov/72169082-test_executable

Replace methadone with optparse and tests
Fix return value
Add test for allocation_mode: 'pool'
Rearrange allocation_mode selection logic to be the same as before
Better wording for vApp fixture test
Update #networks test to explain "none" network

As per @mattbostock recommendations, thanks!