[#67916012, #72866380] Rewrite TestParameters to support fixture setup

Rewrite the `TestParameters` class and add new `UserParameters`,
`FixtureParameters` and `TestSetup` classes so that vCloud Tools Tester
can support the creation and verification of require test fixtures.

The roles are as follows:

`TestParameters` is concerned with retrieving the user-defined
parameters and the parameters it can find by querying the API. To do
this, it calls the `UserParameters` and `FixtureParameters` classes
respectively.

The `UserParameters` class is solely concerned with parsing the
configuration file for user parameters and performing validation of
those parameters.

The `FixtureParameters` class is concerned with ensuring that the
correct fixtures exist in the environment against which the integration
tests are run. As part of this, it will query the vCloud Director API,
compare the existing configuration to the one expected and create new
fixtures if required. Currently, the only fixture it knows to create are
networks.

These changes mean that the method to retrieve the test parameters, as
used by the other vCloud Tools, has changed.

Instead of calling `TestParameters#new`, the test parameters should be
retrieved as follows:

```ruby
test_params = Vcloud::Tools::Tester::TestSetup.new(config_file, user_expected_params).test_params
```

`TestSetup#new` takes an argument `user_expected_params`, which can be
used to specify which user-defined parameters should be present in the
configuration file specified.

We now depend on vCloud Core version 0.5.0, which allows us to query the
vCloud Director API.

Notice that we don't tear down the networks once tests have finished.
There are two reasons for this; firstly because deleting and creating
networks can be expensive operations and secondly because many other
tests rely on these networks and have not yet been converted to create
these fixtures as required.

* * *

If a network with the same name as the test networks already exists, we
check its configuration and raise an error if it is incorrectly
configured for our tests. Raise an error rather than deleting these
networks as it's less aggressive and an existing network with a
different configuration may indicate an underlying issue, i.e. perhaps
the tests are running against the wrong organisation.

Note that we don't check the 'IsEnabled' property of the network
adapters as it's not exposed by the call to
Fog::Compute::VcloudDirector::Collection#all. We could make an extra
call to the API separately but in reality a disabled network is an edge
case and I don't think it's worth the extra API call.

* * *

We use Fog::Compute::VcloudDirector::Collection#all to retrieve the list
of networks in the organisation instead of
Vcloud::Core::EdgeGateway#interfaces as that method does not return
_isolated_ networks, which appear not to associate to a specific Edge
Gateway. Interestingly, the EdgeGateway#interfaces method _does_ return
the 'IsEnabled' property for network interfaces (see comments above).