Re-order methods to clarify execution order

Place the class method `self::validate` before `initialize` to make
it clearer that this class is initialised by calling `self::validate`.

I also wanted to move `valid?` to be after the `validate` instance
method, but the `private` scoping keyword prevents me from doing that;
`valid?` must be public.
Add Rubydoc comments to clarify usage

Add Rubydoc comments to help clarify the execution order of this class.
Sort and re-order methods to aid understanding of code

Move the `validate_array`, `validate_hash` and `check_*` methods to show
first in the private methods to highlight their importance.

The ConfigValidator::data variable will usually be either an array or a
hash, so most validations will call either `validate_array` or
`validate_hash`.

Also sort the `check_*` and other `validate_*` methods alphabetically
for clarity.
Explain recursion

Add Rubydoc comments to explain the recursive calls made in this class.
Merge pull request #56 from alphagov/71740686-document_config_validator

[#71740686] Document ConfigValidator
Doc typo, instance method instead of class method

The `check_hash_parameter` method is an instance method like `validate_hash`
and not a class method like `validate`, so it should have a `#` notation
instead of `::`.
Merge pull request #58 from alphagov/correct_doc_typo

Doc typo, instance method instead of class method
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