`aux/dataTimeSeries` can encode channels in the 2nd dimension

[sstucker]

Proposing this because of request #107 and because of the overhead of HDF5 groups in the Indexed Groups format defined by the SNIRF spec. (#103)

The language describing the ndim of aux/dataTimeSeries was already ambiguous, suggesting a unit 2nd dimension was required (this is different than an array of ndim=1 in the HDF5 format, see #99). This change allows for "channels" in an aux dataTimeSeries with a caveat that 3-dimensional accelerometer sensors should still use individual aux blocks to be more backwards compatible.

We could also introduce a new "ACCEL_XYZ" name in the appendix. The current names are intended to mirror the BIDS nomenclature for the same data, see #81

[samuelpowell]

Would a brief example help clarify that this is not intended to replace the use of ACCEL_X, ACCEL_Y, ACCEL_Z? Something like:

If multiple channels of related data are generated by a system, they may be encoded in the second dimension of the time series. For example, a system containing more than one accelerometer may output this data as a set of ACCEL_X/ACCEL_Y/ACCEL_Z auxiliary time series, where each has the dimension of <time points> x <no. accelerometer>. Alternative uses of the channel data include storing complex numbers, ...

[sstucker]

Yes, your example is more clear, I like it