Feat: Introduce abstract RateMonitor class for unified rate analysis

[Legend101Zz]

Closes #1368

Based on the great discussions and instructions in the issue (thanks, they were really helpful!), I've started the implementation for a unified rate-handling mechanism.

So far, I've created the abstract RateMonitor base class and refactored PopulationRateMonitor to inherit from it. I've also added the new binned() method to PopulationRateMonitor to allow for re-binning of the recorded population rate.

So I guess , EventMonitor is a bit more complex since it handles generic events, not just spikes. I'll need to look more closely at how to pass the correct variable information to the template for that implementation.

Did:

• Added the abstract RateMonitor class.
• Refactored PopulationRateMonitor to inherit from RateMonitor.
• Implemented the binned() method for PopulationRateMonitor.

ToDo:

• Implement the binned() method for EventMonitor to calculate binned rates from event times.
• Thoroughly test the new functionality.
• Write unit tests for the new methods.

[Legend101Zz]

@mstimberg as initially anticipated, adding rate analysis directly to EventMonitor might be a bit more involved. Since EventMonitor supports general events (not just spikes), we’d need to pass in information about which variable should be used for rate calculation to the code generation templates.

That said, I might be overthinking it—perhaps we can restrict it for spikes only :)

[Legend101Zz]

@mstimberg bump on this :)

[mstimberg]

Hi @Legend101Zz. Sorry, I did not yet have time to look into the code in detail, but regarding the EventMonitor: it shouldn't actually change anything here with respect to SpikeMonitor. A few quick remarks:

• the spikemonitor templates have their name for historical reasons only, they are actually implementing the monitor for arbitrary events (they get the name of an eventspace passed to the template, which stores the events that were triggered in the current time step. In the case of a SpikeMonitor, these events are spikes, but it does not make any different if they are something else – the eventspace is always a list of neuron indices.
• for the added binning/smoothing functions we are discussing here, the templates do not come into play, since the whole analysis happens on the Python side after the simulation – the monitors will still record everything in the same way as before.
• For this analysis, it does not matter what the events are, we only need the spike/event trains that give us the times of the spikes/events per neuron. A SpikeMonitor has a spike_trains method because that is the term that is commonly used, but all it does is return self.event_trains()...