The executable expects now a new parameter "subbandSize" which is the
expected number of complex values in each sub-band that the TBB will send.
This allows to stop receiving after we the right number of samples has been
received.  And it allows to report a problem if not.  Also knowing the number
of values per sub-band allows to receive bands out of order but store the data
in the right position in the file.

Offsets can also be negative.  A uint64_t obviously cannot accomodate negative
values.

SW-567: added and used TaskInfoCache for fast lookup of info needed to accept/reject tbb alert voevents. The TaskInfoCache preloads all current information upon start, and then resfreshes itself on task status events, so it's always up to date.

A union makes it clear by using an implicit variable name that in raw voltage
mode the value is a sample number and in spectral mode a band/slice number.

Task SW-560: Added executables to operate tbb via tbbservice, refined recipe according to discussion with Sander

The problem is that C++ interprets [u]int8 types always as characters.  In order
to print that value as a number one has to cast it to a bigger [u]int type.

This variable represents exclusively either a sample or a slice number.
Therefore it makes sense to have a union for a variable itsSampleNr0 for the
transient mode and itsSliceNr0 for the spectral mode.

The value of itsDumpInfo.itsTime0 is checked for 0 in processSpectralFrameData
but if we never initialise it to that then this check can fail and a wrong
offset gets calculated.