Introduce new submodels machinery

This pull request introduces a new machinery to define models. They can be summarized as follows:
1. ty files typically just import a submodel, call the setup() method, if needed change some of the parameters and then instantiate the model by calling the model instance.
2. A deferred instantiation of models is now possible. By calling the setup() method of a submodel, only templates for sheets and projections are created. These templates (SheetRef and ProjectionRef) contain an attribute parameters which is then passed to the actual sheet/projection once the submodel instance is called. SheetRef and ProjectionRef both implement a resolve() method which returns the actual sheet/projection after instantiation. This might be used by Collector.
3. The SheetRef class also has an attribute identifier. This is a dict specifying the sheet more detailed than just the name. E.g. the identifier might be {'eye':'Left','layer':'LGN','polarity':'On'}. The class then overrides the \_\_str\_\_() method to return a string based on this identifier matching the names of sheets which have been used in previous models.
4. The base class for all submodels is SensoryModel. This is an abstract class which provides the structure for the new machinery of setting up models. VisualInputModel is a subclass of SensoryModel, specifying the training patterns of a submodel. EarlyVisionModel is a subclass of VisualInputModel, specifying the retina and LGN sheets. It supports multiple eyes as well as multiple spatial frequency sheets. ColorEarlyVisionModel is a subclass of EarlyVisionModel, and extends it to support color sheets. This class is experimental so far!
5. ModelGCAL is a subclass of ColorEarlyVisionModel (but can be changed without affecting any results to EarlyVisionModel), and specifies V1 according to examples/gcal.ty. Furthermore, it allows multiple lagged projections from LGN sheets to V1 as a motion model.

Submodels lack of more documentation, which will be added soon (see TODO's).

This pull request depends on https://github.com/ioam/topographica/pull/570, https://github.com/ioam/imagen/pull/30 and https://github.com/ioam/featuremapper/pull/10
BTW, the above is just illustrating what I had in mind -- I don't meant to say that it's the right way to do it. E.g. I don't know whether Connectiontype needs a special mapping -- seems like this could go into the connection's parameters, to me.  And I'm not sure it makes sense for Connections to be at the same level as Sheets; seems like in a many-layered system we'd have many different Afferent connections, each with different parameters, and so we'd want to make the Connections be listed under the Sheets.  We can discuss all of this, once the basic idea is clear.