shift annotations timestamps by time_seek during importation

[lucasgautheron]

• shift range_onset / range_offset by +time_seek
• shift segment_onset / segment_offset by +time_seek

This ensures that all timestamps, within the index or the annotations themselves, will match the audio; it will no longer be required to perform any shift after the importation of annotations.

time_seek is preserved as it is useful to keep a record of the shift that has been applied.

@alecristia suggested we add raw_range_onset/raw_range_offset and raw_segment_onset/raw_segment_offset columns (using the timestamps of the input annotations) for clarity. I might add that later

• [x] tests
• [x] documentation
• [x] implementation

[lucasgautheron]

I am not absolutely convinced we should have both the absolute and relative timestamps. I feel people actually have no reason to use the relative timestamps, what's most natural seems having them all relative. This means less code, less documentation, less redundancy, and less bandwidth/memory usage in some cases when it matters (e.g. superdatasets with so many rows such as EL1k). It also means users will need to make no decision about how they use the data as we've made the decision for them already! What do you think @alecristia @sarpu ?