The default value was properly propagated but not visible to the test until a value was sent through the return channel.

This can be overridden by a newly introduced boolean argument. Including the return channel was causing problems e.g. when propagating the DataValidity flag.

need to wait until all mainLoops() are entered, so the initial value propagation is done. Otherwise during initial value propagation values could be read from hardware which might already trigger the exception state.

one initial value was not properly waited for, and one inherent race condition is now basically ignored (with comment)

this was violating thread safety of accessors, since the mainLoopWrapper() was reading initial values at the same time as the test thread was reading the same accessors.

solved a race condition in testTrigger. Initial value was not considered. Still race conditions remaining.

Changes should address timing related failures in the tests.

Fixture teardown functions now ensure the device dummybackends do no
throw on read or write.

- 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()

activated tests for exception flag propagation with direct connection Device->ApplicationModule (part of #102)

All variables from the cs to device have been initialized with a non
zero default before the test starts.

- first part of #102
- Existing tests passing
- New tests not activated yet

Tests for Data invalidation propogation 

    - Basic structure of test application
    - Added modules
    - Refactoring of StatusMonitor to provide a non-templated base class
    - Needs follow-up, for status see issue #14 and the linked follow-up
      ticket

- testInvalidTrigger
- testDeviceReadFailure
- testreadDeviceWithTrigger
- testConsumingFanout
- testDataFlowOnDeviceException

- device1 -> device1DummyBackend.
- device2 -> device2DummyBackend.