bidirectional variables: pass on version numbers in modules from the last blocking read on to any write operations, to resolve conflicts of concurrent variable updates properly

Added preliminary support for bidirectional variables. There are still some known issues, e.g. concurrent updates can still lead to race conditions. This will be addressed soon.

fixed connectTo() for direct device to control system connections when using the [] operator on the device module

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

allow determining a fully qualified name for application variables (i.e. including qualified name of owning module)

renamed VariableNetworkNode getTriggerReceiver() into VariableNetworkNode getNodeToTrigger() for better clarity

When attaching a trigger to a node, the resulting triggered node is stored and later returned when the same trigger is attached again to the same node. This fixes crashes when joining two networks sharing the same node triggered by the same trigger, if the triggering node was technically different.

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.

Made some exception descriptions more elaborate. To achieve this, the dump() functions have been extended to allow writing to an arbitrary ostream.

added preliminary support for tags to application variables which can be searched for and used to generate virtual modules

Rebased the ScalarAccessor and ArrayAccessor classes onto the mtca4u::NDRegisterAccessorBridge class.
Known problems present: code compiles but tests do not run

Fixed a bug that a pointer to a temporary VariableNetworkNode object was sometimes stored (as a trigger receiver or source). Instead now an object with the same data pointer inside is stored.

Read all application inputs once before starting the module threads, so the initial values are correctly present.

For this purpose, additional changes were necessary:
- Added support for constant values as feeders and consumers (just ignore the writes)
- Connect all unconnected application accessors to constants after defining the connections and before creating the implementations
- Renamed the user-overridden function "initialise()" into "defineConnections()", since more actions are now necessary during initialise().
- The connections are now made (i.e. the implementations are created) during the initialisation phase

allow specifying the array length for direct connections between device and control system (as the type is already defined in this case)

Adapation to the unified versions of ControlSystemAdapter and DeviceAccess.

Status: Library compiles, tests do not yet compile.

- performed some code cleaning and refactoring
- store all nodes in a VariableNetwork in a single list, to allow deciding later if a node is feeding or consuming

This commit is an intermediate commit and has known bugs. Almost all tests are failing and the demoApp is not running. Debugging will be done in a next step.

introduced an operator>> and operator<< syntax to connect network nodes. to realise this, the VariableNetworkNode class has been changed into a pimpl pattern.

Allow to make connections directly based on VariableNetworkNodes. This is a first step, more changes have to be made in this direction.