Continuous register access

[aacuevas]

Ported from jonnew/ONI#6

Original text:

Continuous register address
The current ONI specification allows for single register access by writing the relevant parameters to DEV_IDX, REG_ADDR, RW and REG_VALUE in the case of a write, triggering TRIG, waiting for an acknowledge on the signal stream and then, in the case of a read, reading REG_VALUE

This proposal adds the ability to write or read a series of continuous registers by adding a new register ADDR_COUNT.
By default, this register will have a value of 1, in which case register access will operate as usual.
If ADDR_COUNT is set to N>1, then:

ADDR_COUNT will be the number of consecutive registers to access (N)
REG_ADDR will be the address of the first register and will only be need to be written once
DEV_IDX and RW will act normally
For write operations, REG_VALUE will need to be written N times, with the values of the address block. These values will be stored in a temporary buffer in the hardware. Writing less values than required is unspecified behavior.
TRIG will trigger the access to all N registers starting from the address written in REG_ADDR
the signal stream will issue an ACK when all registers have been properly accessed. A NACK will mean an error in any of them. In the case of a write operation, this might mean some registers will be written while others no, so care must be taken
In the case of a read operation, the read values will be stored in a temporal buffer in the device. Consecutive N reads to REG_VAL will return the consecutive values. Reading more than N times results in unspecified behavior.
For compatibility with older revisions, triggering TRIG will also reset ADDR_COUNT to 1, so single register access can proceed as usual following a continuous address access.
Since the value buffer can be different depending on the hardware capabilities, oni-spec info register 0x0010001 will return the max buffer size. Accessing more registers in a single operation than the ones specified in this value is forbidden.

[aacuevas]

Last paragraph, related to #5 and #6 might require further thought (as explained by my second comment in #6 )

This is also related to open-ephys/liboni#8 in a way that, if the hardware is capable, those extensions should use this capability, but if not those functions could still emulate it by software.