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

Assertion is gone, but tests still failing

This is not correlated to the new feature implemented in this branch. It
was needed to compile this version.

Test propagation of data validity and exception in the same cycle

Fix changes broken by renaming to ExceptionDummyBackend in DeviceAccess.

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.

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.

    - 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.

Test application structure:

CS +---> threaded fanout +------------------+
             +                              v
             +--------+                   +Device1+
                      |                   |       |
                      v                +--+       |
  CS   <---------+ Module1 <-------+   v          |
              |       ^            +Consuming     |
              |       +---------+    fanout       |
              +----+            +      +          |
                   v         Device2   |          |
  CS   <---------+ Module2             |          |
                                       |          |
  CS   <-------------------------------+          |
                                                  |
                                                  |
  CS   <---------+ Trigger <----------------------+
                      ^
                      |
                      +
                      CS

They return as soon as the condition is fulfilled, so there is no harm in having long timeouts in case the tests are successful. The only drawback is that it takes longer in case of errors.