Add helpers to create/destroy vApp test fixtures

We need to create and tear down vApps in many integration tests for
Core -- Query, Vapp, Vm at least.

The self.create_test_case_vapps method creates a number of vApps in
a given vDC, with bridged networking to a list of networks. These
can have a configurable name prefix, to help distinguish/separate them
from other tests.

The self.delete_vapps takes a list of Vapp objects as returned by
self.create_test_case_vapps and destroys them.
Switch QueryRunner test to use vApp helper
Fix prefix to not require trailing hyphen
Merge pull request #54 from alphagov/vapp_fixture_helper

[#65713646] Add helper methods to create/delete vApps in tests
Make vcloud-tools-tester available for use
Update CI scripts to get test params from git
Update documentation re vcloud-tools-tester

* Top level README simplified
* Integration test specific README added, detailing how to use vcloud-tools-tester
* Template vcloud-tools-tester config added
update gitignore
Update QueryRunner test to use vcloud-tools-tester
move Core::QueryRunner test to correct dir
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.
Merge pull request #55 from alphagov/add_tools_tester2

[#65363454] Add use of vcloud-tools-tester into Core integration tests
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
Support warnings for ConfigValidator

These are less extreme than errors in that they don't fail validation. The
first use case will be schema deprecations, whereby one param replaces
another.

The consumer will need to check for them with `warnings.empty?`. I'm not
sure it's worth providing a `#warnings?` method equivalent to `#valid?` and
`#errors`.
Support schema deprecations in ConfigValidator

The renaming of `catalog_item` to `vapp_template` in vcloud-launcher has
exposed the need for parameter deprecations in schemas. Because one or the
other is required, but not both, and a warning should be raised if the old
param is provided. This is only supported in the simplest case where the two
parameters exist at the same nesting level in the schema.

We omit the `required` checking for:

- deprecator params if the deprecatee is provided, because it satisfies the
  requirement of one or the other being there.
- deprecatee params, because we should only recommend that the deprecator is
  populated.

There was some discussion about the naming of `ignore_required` because it
could be taken to mean that "a thing called ignore is required" vs "required
can be ignored". We couldn't think of a better name though.

Any logic about deprecations has been deliberately kept out of the method
`check_hash_parameter()`. It shouldn't need to know.

The methods are split into three which each do one thing. This comes at the
cost of iterating over `schema[:internals]` more than once, but it's much
easier to read than when we tried to lump the logic together in a single
method.
Log schema warnings in ConfigLoader

Log any schema warnings (currently just deprecations) that are returned by
ConfigValidator to ConfigLoader. These should be logged before raising an
exception for any errors, so that the user has the chance to fix as many
problems as possible in one sweep.

It's a deliberate decision to implement this in ConfigLoader instead of
ConfigValidator, because it ConfigLoader already logs messages and
ConfigValidator is much more general purpose and may be split to/replaced by
a separate gem one day.