Allow Projections to non-synaptic Populations

[rowleya]

Currently, it is not possible to create a Projection to something other than an AbstractPopulationVertex. This is done to ensure that the receiving Population can represent the connector parameter, which includes a mapping between source and target neurons, as well as change the behaviour of the target population based on the weights and delays specified. In some cases such a mapping is not possible (e.g. external devices) or required (e.g. a live packet receiver), but it is still desirable to have projections to vertices like this, with the understanding that it will just simply receive all the spikes from the pre-synaptic population.

The proposed solution is as follows:

1. Allow the Projection connection to be specified as None (i.e. not specified).
2. Add an AbstractSupportsIncomingSynapticInformation type, with a method add_incoming_synaptic_edge(pre_vertex, synapse_information) (and any other required things).
3. If the Projection is specified with connection == None and the post_population vertex is not of type AbstractSupportsIncomingSynapticInformation, raise an Exception.
4. If the Projection is specified with connection != None and the post_population vertex is of type AbstractSupportsIncomingSynapticInformation, raise an Exception.
5. If the Projection is of type AbstractSupportsIncomingSynapticInformation, call the add_incoming_synaptic_edge method on the vertex when the Projection is created.

[alan-stokes]

A side line for this (but may be its own pull request in general) is to gene rise the master pop and matrix generation in both python and c, allowing said interface to support both gfe and pynn models together, or at a min, partition-able vertices in general.

The changes here would also support that functionality, but the underlying classes would need a bit of redesign.

[rowleya]

This is the "other side" of this issue - that you can re-use the synaptic information in a different context in your application with a simple reusable component. This is also two-fold - you need actual synaptic information in a neural context but you only need edge information in a non-neural context, which might also include other additional information. These can be implemented together clearly but it is worth having both things.

[andrewgait]

There's now the AbstractAcceptsIncomingSynapses type, which I guess partly solves the issue here (e.g the application vertices in SpiNNGym all use it, but stop short of using the synaptic manager at all), but I suspect there's more possible work to be done with regards to live IO and external devices.

[alan-stokes]

i think we handled the other issues with the dependant stuff. so the projection doesn't go to the external device, but to its control core which does the conversion between spikes to commands........ i might be wrong though.