Top level context

This pull request ended up being quite a bit more involved than I first expected. It ostensibly provides support for the `<Reference>` element that was agreed for version 1.0 (see #26). It also removes the requirement that references to child elements are defined in the file before they are used by implementing a lazy loading scheme. Finally, it aims to streamline the loading of nineml files into a single `nineml.read` function, which can load either abstraction layer, user layer or a combination of both from a single file (resolving all references to separate files).

To do this I have introduced a `nineml.context.Context` object, which is derived from `dict` and stores all the top-level elements (checking for valid names). It provides a method `resolve_ref`, which is able to either resolve a local or remote reference or in-line definition depending on what is provided.

The PR passes all the unittests and works for some simple examples but might need a bit more testing depending on how widely the unittests cover as it has required some moderate refactoring (sorry, I know that you were keen to stick to superficial changes Andrew but I had already started work on this branch and I decided that it would be more work to go back and come up with a different way of supporting `<Reference>` objects).

NB: One side-effect is that `nineml.abstraction_layer.ComponentClass` now refers to `nineml.abstraction_layer.base.BaseComponentClass` instead of `nineml.abstraction_layer.dynamics.ComponentClass` but with the introduction of other types of components I thought this seemed to make sense.