Getting rid of the delays, moving some parameters back to StdDataLoop

I removed the delay m_readDelay, it is not needed. But left the g_rx->getWaitTime() as is -- we need to figure out whether we want to encapsulate it inside g_rx->readData() or we just have to keep it in StdDataLoop.

And I moved the other parameters back to StdDataLoop, because they are not delays:

• averageDataProcessingTime is not a delay, it is a timeout, it does not delay anything. In principle, by its logic, it could be encapsulated somehow in the reading of the feedback from DataProcessors. But that's a pain. As it is now, the easiest is just to leave it as a StdDataLoop parameter.
• maxIterationTime is also a timeout, the maximum duration of the StdDataLoop::exec2. When some triggers are lost, StdDataLoop ends the iteration after this timeout passes. (Strips occasionally lose some triggers due to data corruption, most likely it is something that happens on the stave.)
• maxConsecutiveReads is a parameter of StdDataLoop algorithm, the same as in StdDataGatherer. Also, I changed it in StdDataGatherer, from the hardcoded 4096 to a json-config parameter with 4096 as the default value.
• triggersLostTolerance is also just a parameter of the StdDataLoop. From time to time, strips lose 1-2 triggers out of 500-1000 in the calibration runs, but in some situations we want the calibration proceed quickly, ignoring these lost triggers.

The only remaining delay is g_rx->getWaitTime(). In principle, it corresponds to the latency of the HwController. So, it could be encapsulated in HwControllers' RxCore::readData(). My idea was that HwControllers use Clipboards internally for the RX data, and this delay can be moved into the timeout in the Clipboard read. (So, the delay would be converted into a timeout.) But it is not true for all HwControllers.

• It is true for NetioHW, FelixClient, and ItsdaqFW HwControllers (and for StarEmu's EmuRxCore<StarChips>::readData(uint32_t)).
• But some others do not use a Clipboard for RX data, like SpecRxCore::readData, rd53bRegSEETest, PeripheralI2C, BdaqSiTcpFifo, EmuRxCore (and RogueRxCore, BdaqRxCore::readData, EmptyHw). So, we need to check, maybe those controllers can just live without a delay at all. Then we can remove g_rx->getWaitTime() from StdDataLoop. Until then let's leave it there.

So, we need to figure out if we can encapsulate getWaitTime() inside the HwControllers' readData() or just leave it in StdDataLoop. Maybe, the controllers that do not use Clipboards, could implement the timeouting behavior in readData() somehow differently.