This greatly helps debugging real setups, as the messages will usually end up in the server log.
Note: Ideally, a proper logging mechanism should be used instead, but this does not yet exist!

	calling device.getOneDRegisterAccessor<double> causses an error in server,
	when having uder type string

fix tsan complaining about incrementing/decrementing testableMode_deviceInitialisationCounter outside testable mode

should not make a real difference, it is just more logical like this

[wip #173] move clearing error status flag in control system after the point where operations are allowed again (fixes race condition)

A corresponding update of the specification will follow.

- Initial values are sometimetimes only propagated in the first run of the main loops, not in prepare. If other modules are waiting for it they cannot enter their main loop. That's why all threads have to be started first, and only the it is waited for all of them to enter testable mode.

testProcessVariableRecovery: waiting for device to be opened avoids race conditin with runtime error

- recoveryLock now protects the whole critical section
- activateAsyncRead() is called on the device

- removed DeviceModule::waitForRecovery()
- ExceptionHandlingDecorator is throwing to skip transfers

improved places where DeviceModule changes testableMode_deviceInitialisationCounter. Now matches with deviceHasError.

Now the writing in the DeviceModule is working.

Fixes #159

This case was missed in #129.

allows to control whether to wait for device recoveries in stepApplication

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

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

  - add list with shared ptr of transferElements for recovery write
  - add shared mutex

  (first part of #65)

(Currently untested as the recovery does not work in DeviceAccess. calling open() again just does nothing.)

Fixes #53