use corrected timestamps when parsing 2000Hz eyelink data

[dkrako]

Description of the problem

In case of 2000 Hz eye link recordings, the timestamps of the second sample of each millisecond are the same as the first.

Example: raw timestamps: 1000, 1000, 1001, 1001, 1002, 1002

but they should rather be: 1000.0, 1000.5, 1001.0, 1001.5, 1002.0, 1002.5

Description of a solution

In case of a sampling rate of 2000 Hz, the timestamps should be postprocessed after parsing.

Naturally, the second appearance of the same timestamp value should be incremented by 0.5.

In case a timestamp appears just once we have an edge case:

• if there's no direct subsequent timestamp, leave it as .0
• if there's no direct previous timestamp, increment to .5
• otherwise, leave it as .0

The edge case is not that important and can be migrated to a follow-up issue if desired.

Minimum acceptance criteria

• [ ] use corrected timestamps for 2000 Hz data

[behinger]

(toolbox looks great!!)

two minor comments:

• This is (only?) true for eyelink
• I'm not yet sure if you include the events detected by eyelink somewhere, just started checking out the tool. But the automatically detected event-timestamps are rounded down without any way to recover higher precision. This is really a minor thing, as the temporal accuracy to detect such events will never be <1ms - but maybe something to add to a docstring