this fixes #194

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

- 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.

- 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.

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

wip: changed constructor of ExceptionHandlingDecorator to have a VariableNetworkNode as argument instead of a bunch of details

Rearranged processing of fanouts and their consuming nodes. A list of
consuming nodes and implementations is passed to the fanout constructors,
so the nodes don't have to added later. This resolves conflicts in the
order in which accessors are decorated and added to the fanouts.

FanOut constructors could still use refactoring.

Ongoing refactoring. Consuming fanout works again.

Now the writing in the DeviceModule is working.

Fixes #159

allows to control whether to wait for device recoveries in stepApplication

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.

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

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