DM3/DM4 reader: improve initialization performance

[sk1p]

As a follow-up to #291, we may want to try to improve the initialization performance of our reader. By executing the metadata reading for many files concurrently, we already got the time down to ~20 seconds for a 2.5k data set, from more than two minutes (IIRC). This can be further improved if there is need, for example for even larger data sets.

Possible improvement, roughly ordered by increasing difficulty:

• offset guessing - one can read a single offset, for example from the first file. Then, one can search in the following files of the stack for a specific byte sequence (0x0f 0x0004 "Data" "%%%%" or something along these lines) to find the correct offset. This is hacky (and can fail spectacularly if there happen to be multiple smaller images in the file), but allows us to sidestep the expensive parsing of all fields just to get the offset. Documented for example by Chris Boothroyd at https://www.ntu.edu.sg/home/cbb/info/dmformat/index.html
• pruning in DM4: DM4 (as opposed to DM3) includes the total tag length in each tag - this means we can skip whole branches of the tag tree and only descend into those that are really interesting for us - for example, we could skip all root tags but ImageList to just read the offsets
• optimize the parser, for example using cython or a pure C (or rust?) implementation, with a python interface

[sk1p]

Related to offset guessing: can also read the correct offset from the first file, then validate for the rest of files, and fall back to the slow case if validation fails. Validation can be done by storing offsets for arraySize, arrayOffset, DataType tags from the first file and checking if the values of the tags at these offsets are the same.