Add tests for sticking points

[ajtucker]

Sticking points include:

• The JSON response we get back from sapi-nt doesn't often include @type declarations of the main resource or any nested properties. We need to rely on the declared type of the main resource and its properties in the model.yaml to look up any implementing Ruby class and to figure out what properties/methods to allow in responsds_to? and method_missing.
• If we do get a @type or many @type declarations back, these still might not be the most specific type of the resource.
• Some properties might have more than one range. In sapi-nt modelspec, this means that the property can be any one of the given types.
• Name clashes. In reality, each RDF namespace should be in its own Ruby module. In practice we at least need to put each different parsed model.yaml into its own Ruby module, much like the Gems declare the methods in e.g. Fsa::Rp::Api etc. This will need to be done for the type signatures in the various API Gems too.
• "Polymorphism" in sapi-nt is declared on a super class if you want to be able to use specific properties of a subclass, e.g. list all authorisations (superclass) with a property environmentalMonitoring, which is only declared on GmoAuthorisation (subclass of Authorisation). I'm not sure whether this will bite us, though we could do with coming up with some tests to check the boundaries.

Once we have up to date API specs from #80 and can update the VCRs from #79, we can add tests for some of the above against the real example responses from the API to check that we can figure out the types of resources where the information isn't provided, get the right properties implemented and map to the right implementing Ruby classes.