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

- Exception handling decorator and ThreadedFanOut send condition variable notificatios via the DeviceModule
- FanOut sends terminate to impl and all slaves.
Solves (some?) shutdown issues, but breaks bi-directional array test.

supposedly fixed implementation, but tests are conceptually broken and/or implementation cannot be terminated

- fixed bug that there was a nullptr exception handler in the list with default value from constructor (caused all ApplicationCore to fail)

first implementation of device initialisation handler. Simple test passes, but needs to be extended.

implemented first interface change in DeviceModule to support initialisationHandlers. Test in place but failing due to missing implementation.

changed: device is not intialized in constructor anymore.

Test still does not work.
-Unable to get the exception status for the device throwing exception.
-Second device only works it has it's own trigger.

According to ChimeraTK/DeviceAccess#61 Devices will no longer close on their own (e.g. when throwing an exception). The exception handling now takes into account that the device always stays open