Convert specs to RSpec 2.14.8 syntax with Transpec

This conversion is done by Transpec 2.1.0 with the following command:
```
transpec
```

This change means our tests consistently use the `expect` syntax. The
old `should` syntax is deprecated in Rspec 3[1].

[1]:
https://www.relishapp.com/rspec/rspec-expectations/docs/syntax-configuration

* 92 conversions
    from: obj.should_receive(:message)
      to: expect(obj).to receive(:message)

* 23 conversions
    from: obj.stub(:message)
      to: allow(obj).to receive(:message)

* 19 conversions
    from: obj.should
      to: expect(obj).to

* 14 conversions
    from: obj.should_not_receive(:message)
      to: expect(obj).not_to receive(:message)

* 5 conversions
    from: == expected
      to: eq(expected)

* 4 conversions
    from: Klass.any_instance.stub(:message)
      to: allow_any_instance_of(Klass).to receive(:message)

* 2 conversions
    from: expect(obj).to receive(:message).and_return { value }
      to: expect(obj).to receive(:message) { value }

* 1 conversion
    from: lambda { }.should
      to: expect { }.to

* 1 conversion
    from: obj.should_not
      to: expect(obj).not_to

See also: https://github.com/yujinakayama/transpec#supported-conversions
Disable `should` syntax in Rspec

`should` syntax is deprecated as of Rspec version 3.0 and the previous
commit converts all of our tests to use `expect` for consistency.

To prevent regressions, this change disables `should` syntax for this
gem.
Fix indenting for comments in ConfigValidator

The Rubydoc comments under the heading 'Recursion in this class' were
being formatted as code by [Yard](http://yardoc.org/) because of they
were indented.

Fix the indentation so that the comments are formatted correctly.
Rubydoc comments were showing for module not class

Move the Rubydoc comments intended for the Vcloud::Core::ConfigValidator
class.

[Yard](http://yardoc.org/) was associating these comments to the
`Vcloud` module; move them so that they appear under the
`ConfigValidator` class.
Thank external contributors
Merge pull request #76 from alphagov/thank-contributors

Thank external contributors
Merge pull request #72 from alphagov/transpec-convert

Convert Rspec tests to use `expect` syntax
Merge pull request #73 from alphagov/fix-rubydoc

Fix Rubydoc comments for Vcloud::Core::ConfigValidator
Create fixtures for EdgeGateway integration tests

Add a new helper function for the Vcloud::Core::EdgeGateway integration
tests, IntegrationHelper::ensure_networks_correct, that checks if the
networks required for the integration tests already exist in the test
organisation and if not, create them.

These fixtures are re-used
--------------------------

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. I'm no longer convinced that setting up and
tearing down the networks before and after each test run is so
expensive, so it's worth reexamining this once all of the other tests
are able to setup their fixtures as required (see story 67916012).

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.

Impact on other integration tests
---------------------------------

As these network fixtures are currently undocumented, these tests impact
the other integration tests both in this gem and in the other vCloud
Tools gems. The steps to make these work are:

1. Delete the existing networks in the CI environment via the vCloud
  Director GUI.

2. Run just the Core::EdgeGateway integration tests using `bundle exec
  rspec spec/integration/core/edge_gateway_spec.rb`.

3. Ensure that `network_1_ip` and `network_2_ip` are set to
  `192.168.1.2` and `10.0.0.2` respectively.

4. Once the Core::EdgeGateway tests have run, set the '_id' test
  parameters to the UUID used by the new networks that have just been
  created. You might need to use vcloud-walk to do this. This is
  necessary so that integration tests not using this helper method
  continue to function.

5. All tests should now run successfully.

IsEnabled
---------

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.

Retrieving the list of networks
-------------------------------

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).

Test parameters that we ignore
------------------------------

We define an array of test parameters (populated with values from the
vCloud Tools Tester gem) so that we can modify the parameters later.
This is necessary so that we can set the network UUID (`network_1_id`
and `network_2_id` specifically) if the networks have been created by
the IntegrationHelper::ensure_networks_correct method.

The '_id' parameters are effectively now ignored by the
Core::EdgeGateway integration tests as we set these by querying the
environment.

Once other gems have been updated in the same vein, we should remove
these as test parameters so that they are no longer read from the
configuration file consumed by vCloud Tools Tester.

We may need more flexibility in the vCloud Tools Tester gem either so
that test parameters can be modified, or so that vCloud Tools Tester
assumes the responsibility of setting up test fixtures.