This prevents stepApplication() to return too early (e.g. right after start) when the device is not yet initialised.

Note: is has been verified that there is no race condition at the beginning despite the counter is only incremented during the test (by introducing an artificial delay at the beginning of handleException()). It works, because testable mode waits until all devices are opened. In testable mode, this check is now equivalent to the devices being also initialised (when the testableModeLock is obtained and the counter is checked).

	-waitting for recovery is now outsourced in function
	DeviceModule::waitForRecovery()

	-everywhere where the function is called, the new function is now called.

Fixes #144

fix not using a ConsumingFanOut when connecting the two poll-types each with a push-type variable (e.g. control system)

this happens frequently when following the modern connectTo() logic and connecting everything with the control system.

- The direction cannot be determined from the accessor which is being decorated
- Fixed wrong usage of feeding/consuming in Applicaton::createDeviceVariable. Was used consistently wrong, so there was no behaviour bug. But the code was confusing because the direction was wrong.

Tests still failing.

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

Assertion is gone, but tests still failing

This is to support when running under Boost::Test which will swallow the
message otherwise and print the confusing ~AppBase() message of not
being properly shut down

This partly reverts the last commit as would trigger writeAll from
typedMtypedMakeConnections and causes errors.

  - Rewrite on exception counter change
  - getDataValidity respects exception and dataFault counters

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

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

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

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

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