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

Use one file per class. Also, use boost::core::demangle instead of
checking for abi::__cxa_demangle by ourselves.

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)

allow connecting a consuming node to a consuming node, if one of them already has been connected to a feeder.

renamed VariableNetwork::addTriggerReceiver() into VariableNetwork::addNodeToTrigger() for better clarity

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)