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.

		add bool thereHaveBeenExceptions
		write test for taht
			testExceptionsDummyDevice.cc

wip #47: add test for direct connections from ConfigReader to a device. The test is currently failing.

		writeAfterOpen writes constants to devices
		remove writeAfterOpen in recovery loop
			that should be in writeRecoveryOpen
		extend testProcessVariableRecovery for constants

  - Handle illegal writes to read-only accessors in doPreWrite().
    Otherwise, attempting to write to the recovery accessor would result
    in a nullpointer access.
  - Related test case.

test was broken by its design, which became now evident with the proper initial value propagation