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

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.

Test application structure:

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

Fix broken propagation of initial values

Issue87

Issue82

Wip mhier issue47 config reader and exceptions

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.

wip #47: register accessor for write after open in DeviceModule if write cannot be performed in initialisation phase