Compute saturation intervals ala IBL

[oliche]

This PR ports the saturation method from IBL. It will introduce a new data type for holding information on events / periods of noise / saturation etc.

This will also require:

• update 'silence_artefacts.py` to output this new data type
• update silence_periods.py to handle this new data type

Other notes:

• remove_artefacts.py handles a slightly different use case (triggers at known timepoints contaminating the recording, which may also be imputed with a model-based approach) and so is not considered here

Questions:

• Currently in compute the data is cast to float64 and then scaled with gains and offset. To confirm, is there any situation where this data might already be scaled? I guess if the data is scaled, gain is 1 and offset is 0 anyway.
• float64 was chosen for the extra precision as IBL are working in volts
• should mute_window_samples be scaled based on the fs? (currently 7 samples assumes NP1)
• I forget is return_scaled or scale_to_uV preferred now? Just a note in the docstring
• Are data for all probes scaled to uV? initially I wrote this to specify the arguments should be uV but I changed it to be more general units in case probes differ on this
• @oliche could you double check the units in the detect_saturation() docstring? I will also double check but good to get another pair of eyes on this

To discuss

• There was some discussion on applying this directly in the int16 space, but because its a saturation of the amplifier not ADC I think it was determined not to do this. But I don't have a strong grasp on this so will leave to @alejoe91 @oliche to discuss.
• In Refactor artifacts detection + add sturation detection #4297 @samuelgarcia this is merged with a envelope-like calculation. I (Joe) am still not convinced these methods should be merged, as this is qualitatively different to the envelope method and should be applied in a very different way. I think it will be very confusing to users that this meta-method should be applied in one way with one argument, and a different way with another argument.

Documentation
It would be nice to add a documentation page for this once the applier-function is done as the application is a little non-standard i.e. should be estimated on the raw data, and applied on the preprocessed data. Some of the values should also be empirically estimated / are dependent on the probe, this has really designed for NP1 as I understand it.

[alejoe91]

Can we apply this directly in the int16 space?

[samuelgarcia]

Hi @oliche @JoeZiminski
I copy paste and clean a bit this PR into the one I started already here #4297
Have a look and tell if this is OK.

I think we do not need to scaled traces at each chunk we could only could the unscaled threhold in the init and then we could avoid the costly convertion to float32 or float64.

Also I put the unit in uV to be more SI friendly.