Ptp fix

[dkluger]

This is a pull request for merging in changes to the class NsxFile to allow for files with 1-sample segments in continuous data. This allows for PTP timestamping of continuous data. The method getaligneddata() allows for continuous data frame copies/removals to allow for PTP-timestamped data to be aligned to the "true" sampling rates (30 kS/s, 10 kS/s, etc). This allows data recorded from a Gemini NSP and Gemini Hub to be aligned for analysis after alignment.

[cboulay]

I made quite a few changes in 2f06cf6. I'm sure I'm forgetting some, but here's what I can remember, in no particular order:

• Replace usages of MAX_SAMP_PER_S with self.basic_header["SampleResolution"] in case we every get away from 30_000 base sampling frequency.
• add force_srate kwarg. Set this to True to force the segments to have exactly the expected number of samples in the given time stamp range. Only applies to ptp-timestamped data. Note: Current insertion method uses the average of 2 neighbouring values while previous implementation duplicated the preceding value.
• add full_timestamps kwarg. Setting to True will return per-sample timestamps for each segment. These might be the recorded timestamps, or idealized timestamps if either old filespec or ptp times and not force_srate. Default is False which preserves previous behaviour.
• add elec_rows kwarg. Setting False (True by default) will return the data with shape (samples, channels), which is C-contiguous w.r.t. how it is stored on disk. True preserves previous behavior.
• Refactored data loading. More details below.
• Readded zeropad functionality which had been commented out, even though the kwarg remained. Will print a deprecation warning if set True.
• Fixed some logic bugs
  • It's now possible to extract segments from ptp data even if not doing realignment
  • inserting / removing samples weren't evenly distributed (e.g., 2 samples at 0.25 and 0.75, instead of at 0.33 and 0.66)
  • a couple others I'm forgetting.

The data loading is now lazy, and as such is no longer deferred until after header inspection. This simplifies logic and lazy-loading drastically speeds up function return time. The data won't be loaded into memory until the user slices the data. If they are only slicing specific segments, or using a rolling-window for analysis, this will lead to greater performance and few memory bottlenecks.

However, using either zeropad or force_srate might cause the data to be loaded into memory because the returned array is modified with data not on disk, so it's impossible to do lazy-loading.

@dkluger , this probably needs a re-review now, but I'll mark it as ready.