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

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.

Unfortunatly this currently breaks the ServerHistory module, as it relies on slashes in accessor names. The MicroDAQ module had the same issue but has already been fixed. This fix can be adopted to the ServerHistory module as well.

Fixed wrongly created hierarchies when directly connecting a device to the controlsystem using connectTo(). Now proper virtual submodules are created for each hierarchy level, insted of keeping the slash in the variable name.

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

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

fixed not creating some of the application varibales with wait_for_new_data despite they were specified as push inputs

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

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

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

necessary changes for the latest DeviceAccess update (readAsync() return type no longer a reference, and other related changes)

Changed an exception into an assert, since the function is only internally used and the exception is never thrown. Clafiried the documentation about this.

removed incorrect implementation of operator[] and operator() in ApplicationModule (and use the implementations of ModuleImpl instead)