Timing the computations of quality metrics and some optimizations

[yger]

This PR is left open, but after playing with real-size datasets during the hackathon amazingly organized by our "ami du bouchon" @samuelgarcia , I realized, that some persons might consider spikeinterface too slow. And because we want everyong to join the game (the more the merrier), we need to be inclusive. During the hackthon, we've worked to solve the problem with cross-correlograms (see #4305 and #4307 ). However, we might wonder what can be done for the other metrics, and to do so, first thing is to time the metric. This is what is now added by the PR

For a 1000s recording with 1000 units, you can immediatly see some issues, that I'll try to fix in this open PR. Some metrics, for example, are using suboptimal correlograms (numpy implemetantations), and some others I guess should be optimized. At least, now metrics can be timed

{'num_spikes': 21.245169458998134,
'firing_rate': 0.0007224159999168478,
'presence_ratio': 0.14417108400084544,
'snr': 0.040033251003478654,
'isi_violation': 0.049835821002488956,
'rp_violation': 3.409717330003332,
'sliding_rp_violation': 7.334715744997084,
'synchrony': 21.48789839699748,
'firing_range': 0.36698940899805166,
'amplitude_cv': 28.745208095002454,
'amplitude_cutoff': 0.5351223960024072,
'noise_cutoff': 0.8977982619981049,
'amplitude_median': 0.4023318469990045,
'sd_ratio': 48.09409817199776}

With the PR, we now have:

• {'num_spikes': 0.12104277299658861}
• {'sd_ratio': 2.566413887994713}
• {'amplitude_cv': 4.915091472001222,
• {'rp_violation': 1.7641781819984317}

[samuelgarcia]

Pierre notre héros.

[samuelgarcia]

I realized, that some persons might consider spikeinterface too slow.

No name please.

[samuelgarcia]

I would also consider that slow computation should be removed of the by default metrics.
No ?