this was never really a problem, since it was always used with the BidirectionalProcessArray() which implements writeDestructively same as write

Need to wait until the internal fan out threads have been launched and acquired the testable mode lock before continuing with app starting and testing to avoid race conditions.

wip: fix propagation of initial values from control system variables (persistence layer) and device registers (just the current value)

- Exception handling decorator and ThreadedFanOut send condition variable notificatios via the DeviceModule
- FanOut sends terminate to impl and all slaves.
Solves (some?) shutdown issues, but breaks bi-directional array test.

- implement ThreadedFanOut version with return channel
- add test for ThreadedFanOut with return channel

Updated to use the new ReadAnyGroup instead of the old readAny function. Some tests are still hanging or failing (mostly due to shutdown issues)

Renamed Application::testableModeThreadName() into Application::threadName(), since this will be used for other purposes as well.

- add all networks triggered from the same node to the same TriggerFanOut
- put all feeding nodes in a TriggerFanOut into the same TransferGroup

- added some class documentation