Currently does exactly the same as before, but should help us
introduce more flexibility, particularly to customise for
different versions of the LabView setup.

To have full access to the header information (not used yet, but
it will be to check for variable resolution/shape), we need to
create the reader earlier on, since we don't store the header
object anywhere. This also lets us use the reader across
different methods if required (e.g when adding the acquisitions
for each ROI).

Right now the Readers for newer versions don't do anything
different, but some of the structure is there to allow them to.

currently fails for v300, as expected

this can (at least currently) only happen in post-2018 versions (2.3.1
and 3.0.0) of LabView, because the latter have trial information in the
header files. In the pre-2018, the speed data is the only way a
deduction of trial times is possible, so in this case we can't do
without a speed data file (and a ValueError is raised.)

This set of changes involves transferring some calculations from the
epochs (which contain the speed data) to the trials in the file. A
side-effect of this are small signature changes, due to the 1e-9 small
difference in start and stop times between epoch and trial.

trial and epoch start_time and end_time are now consistent with each
other.

tests fail for pointing mode sample data (but not for the miniscan).
the shapes and datatypes etc all match up, but the signature values are
different. This is expected because it seems, at least for the pointing
mode, the values in the TDMS file are written as
(roi1_cycle0,...,roi10_cycle0, roi1_cycle1,...,roi10_cycle1,
roi1_cycle2,...) and we are reading the first cycles_per_trial values
for roi0. But I don't understand why the miniscan test passes?

However, this code does create a reasonable-looking variable roi file for real life
data (more tests needed in the future for this though)

The failure is related to the order of things inside the TDMS file, and
the code executed in the two inner loops (channel and roi) of
_write_roi_data. But I am struggling to figure out how one would do this
well.

Maybe we need to handle legacy and variable roi code completely
separately, although it would be more elegant if we didn't have to do
this.

rois.py now stores copy of ROI.dat as a dataframe
and gives access to n_lines_in_roi, pixels_per_line and n_rois

calculation of n_lines_in_roi and pixels_per_line moved from timings.py to
rois.py

adapt timings.py formatting to accommodate variable size rois

timings tests inelegantly avoid using abstract factory pattern
(get_reader) and instantiate subclasses directly, but simpler
this way because we don't need to create synthetic header files.

Without the copy, creating an instance of a RoiReaderv300 would
change the column list (and other attributes) of any existing
readers, even the ClassicalRoiReader. This isn't an issue at the
moment because we only ever use one reader for the whole runtime,
but there's no reason it should.

Split the size lookup in two steps: for pointing mode, it's shared
for all RoiReaders, but for miniscans the method is different.

Also, moved the new behaviour (using the num_lines and
pixel_per_miniscan columns) to the base v3.0.0 class, rather than
the subclass for variable shapes, since the new columns are used
in the new LabVIEW setup regardless of whether variable ROIs are
allowed (I think!)

Partly reverts 4fb96 to simplify the code a bit. Document the
difference in how we store times between trials and epochs.
Also set `trial_times` in all cases, whereas before it was only set
for newer versions. This lets us use it throughout the file.

- It seems the line numbers and pixels can be read directly from
the corresponding column, regardless of the angle.
- We still need to add the epoch name even if there is no speed
data (should have been part of 8db9623).
- `get_roi_imaging_plane` should maybe change so that it takes a
0-based index, like the other methods (or the other way around).

We should make a smaller version of this. I edited the signature
file manually after renaming the input directory, so there may be
some inconsistencies that still need correcting!

num_lines was changed by programmatic manipulation, without running
the tests. If the tests pass for these files, I'm confident that
the signatures for the remaining ones can be overwritten by
generating them again with the latest version of the code.

- Pandas will stop liking indexing with [:, np.newaxis], and we
need to get the underlying numpy array instead.
- np.sum will change behaviour when a generator is passed; we can
use the builtin sum instead.
- The syntax for accessing the channel data in nptdms has changed.
- Mapping has been in abc.collections for a while now, and the old
import will stop working in Python 3.9.

As with some other datasets, on some platforms these are stored as
32-bit and on others as 64-bit.

using the convert_num_lines_to_int.py script on
the files where the sigs weren't update yet

~25000 pixels need more than an 10 bit mantissa to represent ints
correctly.

...with Lena's data (200228_14_15_57)

…tionality