- Exception handling decorator does not allow to leave testable mode before
  devices are up
- Test facility makes sure that testable mode counter is zero at the end of startApplication()

change declaration of 'decrementDataFaultCounter' in 'EntityOwner' to take a bool parameter and adjust rest of the code to it
implement 'decrementDataFaultCounter' in 'ApplicationModule' according to ticket #95 -> rewrite all outputs when 'faultCounter' goes from 1 to 0

size_t has different types on 32 vs 64 bit systems. UL is correct for
64. Just use the ::size_type define to help it figure it out properly

Martin Killenberg authored 5 years ago and Martin Christoph Hierholzer committed 5 years ago

Creation of fanOuts is based on externalTriggerImpl (=trigger consumer), not externalTriggerNode (=trigger feeder).
- Fixes connection network but not exception handling.
- Lots of debug output left in the code for further investigation.

- add test for full exception handling

- treat the two directions of bidirectional variables properly in testable mode (i.e. as individual variables with each one counter)
- fix a data race in testable mode in case a bidirectional variable rejected a value (was not holding a required lock)

Fixed getCurrentVersionNumber() and setCurrentVersionNumber() so they always get/set the version number of the ApplicationModule and not e.g. of a VariableGroup.

Implemented bidirectional process variables for control system variables. There are still bugs and the test is failing...

Include descriptions of the owning Module in the descriptions of each process variable to make them more complete.

Updated to use the new ReadAnyGroup instead of the old readAny function. Some tests are still hanging or failing (mostly due to shutdown issues)

We have a visitor now for generating
 - the XML
 - the Module's dot graph
 - the textual dump of the VariableNetwork
 - the dot graph of the VariableNetwork

It inherits two functions from its two base classes. Explicitly use the
one from ApplicationBase.

use a different work around for the thread_local problem: moving the code using the thread_local specifier to the cc file also solved the problem and does not require a complicated work around using a map...