Handle events

[alejoe91]

Right now, the GUI has no notion of events. Allowing users to pass events could open up for several enhancements and new views:

Existing views:

• TraceView/TraceMapView: select event types and move to next/previous event
• ScatteViews: display events on top of scatter

New views:

• TimeAlignedRasters: rasters for one or multiple units aligned with specific event types
• PSTHs: construct and view PSTHs on the fly

My proposal, for now, is to have the run_mainwindow accept an events argument, structured as a dictionary, where users can either provied 'time_s' (plus optionally 'duration_s') or 'sample_index' (and optionally 'duration_samples').

{
    'event_label1': {
        'time_s': [...],
        'duration_s': [...],  # optional
        'sample_index': [...],  # optional
        'duration_samples': [...]  # optional
    },
     'event_label12': {
        'time_s': [...],
        'duration_s': [...],  # optional
        'sample_index': [...],  # optional
        'duration_samples': [...]  # optional
    },
}

@samuelgarcia @chrishalcrow what do you think?

Note: we need to be able to handle timestamps (see #181), since when providing times we assume they are synced with the recording timestamps