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

refactored a type if-then-else monster into a for_each loop and exlcuded a pure cout function from the converage report

- clarified some comments

fixed connectTo() so it now uses the dynamic/virtual model and thus obeys e.g. eliminated hierarchies etc.

Renamed Application::testableModeThreadName() into Application::threadName(), since this will be used for other purposes as well.

Instead of making the DeviceModule return the same VariableNetworkNode for the same register, an optimisation step before realising the connections (but after all connections have been defined) is performed. In this step, all networks sharing the same (device-type) feeder will be merged. This is more flexible and avoids problems with (potentially different) triggers etc.