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 #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?