Add shift_times to BaseSorting

[h-mayorquin]

BaseRecording has shift_times (#3509). BaseSorting got get_start_time/get_end_time in #4525 but no way to shift the timing through the public API. This PR adds shift_times to BaseSorting.

shift_times on a sorting never mutates the registered recording. After #4525, register_recording copies the recording's start time into each segment's _t_start, so _t_start represents the effective start time of the segment. shift_times(delta) adds delta to _t_start. When a recording is registered, the effective shift relative to the recording is _t_start - recording.get_start_time(); this is 0 right after registration and becomes 5.0 after shift_times(5.0).

sample_index_to_time, time_to_sample_index, get_end_time, and get_times now compose this shift. I also updated the get_unit_spike_train_in_seconds native path (used by NWB extractors) which previously ignored _t_start.

[chrishalcrow]

Looks great! I think we should add a check on create_sorting_analyzer that the start times for the recording and sorting match. I can't imagine a situation where you'd want them to not match, but can imagine accidentally shifting them out of sync.

[alejoe91]

Looks great! I think we should add a check on create_sorting_analyzer that the start times for the recording and sorting match. I can't imagine a situation where you'd want them to not match, but can imagine accidentally shifting them out of sync.

@h-mayorquin LGTM! I agree that the check that @chrishalcrow proposes doesn't hurt :) Can you add it to this PR?

[h-mayorquin]

I tried the create_sorting_analyzer improvement suggested by @chrishalcrow but I reverted. There are some design decisions to be made over there (e.g. what happens when an unregistered sorting paired with a non-zero-start recording raise, something that happens on the test) and I think they should be made by someone who users the sorting analyzer more than I do. I will have to get my hands dirty with the analyzer soon and then maybe I can take a stab at that.