Simply add timeout to acquiring the testable mode lock and print an error message with the last thread which successfully obtained the thread. Finally throw an exception to help debugging.

to check whether stepApplication() can execute...

This generates graphviz code to visualise the connections between modules

Just use enableDebugDataLoss() to enable debug output.

- Implemented but not tested yet
- All existing tests passing

Co-authored-by: Jens Georg <jens.georg@desy.de>

Prints a clear message if a circular dependency of initial values exists.

Rearranged processing of fanouts and their consuming nodes. A list of
consuming nodes and implementations is passed to the fanout constructors,
so the nodes don't have to added later. This resolves conflicts in the
order in which accessors are decorated and added to the fanouts.

FanOut constructors could still use refactoring.

- removed ExceptionHandlingDecorator::setOwnerValidity()

Ongoing refactoring. Consuming fanout works again.

allows to control whether to wait for device recoveries in stepApplication

- All accessors come up in exception state.
- Read-accessors increase counter in init phase

Assertion is gone, but tests still failing

  - EntityOwner has individual counters for both events
  - Adapted all instances of increment/decrementDataFaultCounter
  - Not changed getDataValidity() implementation yet
  - Tests failing

- Exception handling decorator does not allow to leave testable mode before
  devices are up
- Test facility makes sure that testable mode counter is zero at the end of startApplication()

change declaration of 'decrementDataFaultCounter' in 'EntityOwner' to take a bool parameter and adjust rest of the code to it
implement 'decrementDataFaultCounter' in 'ApplicationModule' according to ticket #95 -> rewrite all outputs when 'faultCounter' goes from 1 to 0

size_t has different types on 32 vs 64 bit systems. UL is correct for
64. Just use the ::size_type define to help it figure it out properly