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