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
These functions including the corresponding mappings still need to be replaced by something else. However, I am not sure what that should be. I think we all agreed that there should be a single method doing the job of the 4 different mappings ``sheet_parameters_mapping``, ``sheet_matchcondition_mapping``, ``match_parameter_mapping`` &  ``match_connectiontype_mapping``; as well as combining ``_set_sheet_parameters``, ``_set_sheet_matchconditions`` & ``_set_projection_parameters``.

I am not sure though how this method should look like. The idea about the mappings is that each level can add the corresponding mappings. Therefore, the method would need to be overridden in all subclasses. Which attributes are passed to this method? The name of the specification and some string specifying whether one wants parameters, connection_type or matchconditions? How would the internal data structure look like? Would it still have the 4 different mappings, but internally?
Jim, you spoke about a dict within a dict. How do you imagine the internal data structure? And where/how is this structure fed?