was already removed for the ScalarAccessor and is tested at least there

This reverts commit 4f2b35be.

Was actually used and tested.

this was never really a problem, since it was always used with the BidirectionalProcessArray() which implements writeDestructively same as write

It already exists for ArrayAccessor::readAsync()...

transform logic_errors in doXxxTransferYyy that are already checked in the preXxx functions into asserts

Fixes #153

Now the writing in the DeviceModule is working.

Fixes #159

* doGenericPostAction is void
* removed endless loop in doGenericPostAction
* only wait for recovery if application is running in multi-threaded mode
* fixed return value for doReadTransferXxx in case transfer is not allowed

Fixes #151

	TODO doGenericPostAction
	DONE all the rest

	does not compile, due to missing overrides

allows to control whether to wait for device recoveries in stepApplication

ScalarPollInput and ArrayPollInput: Removed doReadTransfer, which does not make sense in the interface

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

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

Replaces calls to doXxxTransferYyy of the TransferElement by the
corresponding xxxTransferYyy call

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

  - 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