Times propagation to preprocessing and other modules

At the moment as I understand it set times do not predictably propagate to preprocessing steps, (i.e. I think some use them but some dont, this has come up in #3509 and #3519). In general I am not certain what areas of the codebase they have been extended to (e.g. off the top of my head I guess this is not really needed for preprocessing? I'm not sure the status of all the different widgets).

I think there are two approaches, as extending times throughout the codebase is a big job (?). One is to really reduce the scope of times, make it settable on the sorting object only and very explictly state that it is only used for setting the spike times after sorting, which I think is the main use case. The other is to 'audit' all preprocessing, postprocessing steps and widgets to check if timings are required. Having a quick look, maybe it is not so bad, not many preprocesing steps at least explicitly use time periods, and where they do they take the frame e.g. silence periods. Many use time parameters e.g. margin_ms but as long as there is a sampling rate the absolute times don't matter @h-mayorquin I think this means we will always have to have a sampling rate of some kind, e.g. as the average rate for non-evenly sampled data.

Anyways, I don't have time to do this 😅 but just raising so it is on the radar, as I think this is quite confusing for users, and also to get some clarify for myself on where times are / arn't used.

Start by inspecting how times are handled on the sorting object and in preprocessing steps such as silence_periods, then review postprocessing and widget references. Check how frame-based periods, margin_ms, and sampling rate interact with absolute times. Done means the propagation scope is audited and the supported behavior is clearly defined.