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!

remove unnecessary and wrong (not thread safe) increment+decrement of the testableMode_deviceInitialisationCounter

this fixes #194

Prints a clear message if a circular dependency of initial values exists.

Poll-type reads are blocking until the initial values are available, hence the testable mode must be released in case the initial value is not yet available.

	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.

- Also removed race conditions in the test.

- Version number in exception case is always the same.
- Remembers that it has reported an exception so a readLatest() after recovery does not switch the data validity back to ok if there was no new data.

- All variables conceptually have an initial value now.
- All initial values read by blocking read() before starting the main loop.
- More tests failing, probably to old test exceptiations and wrong test implementations.

- tests still failing
- modifications incomplete
- cleanup needed

- 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

Only the blocking read in wfnd TEs will update the module's version

This reverts commit bc329233.

We propagate the version to the module on any read, if it is on an
accessor with wait_for_new_data and there is new data (for
readNonBlocking/readLatest)

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

For receiving variables, the validity should be faulty after
construction, see data validity propagation spec 2.6.1.

restored write functionality of MetaDataPropagatingRegisterDecorator in case of locally set faulty status (DataValiditySpec 2.1.5)

Removed obsolete localValidity.

Removed obsolete localValidity.