- ControlSystemModule
- VirtualModule
- findTag
- excludeTag

and some related functions.

When writing special modules (e.g. the MicroDAQ module) it may be necessary to both override and call this function explicitly.

- Implemented but not tested yet
- All existing tests passing

This actually makes the implementation also easier and more efficient.

* add HierarchyModifyingGroup

* VirtualModule: allow nested oneLevelUp etc.; simplify implementation

This is achieved by properly setting the _owner of each VirtualModule (unless highest level).

The simplification comes from then being able to use getOwner() instead of keeping track of "grandparents", and from using createAndGetSubmodule() instead of implementing something similar again in findTagAndAppendToModule().

* DataLossCounter constructor now takes qualified path to trigger variable

- Initial values are sometimetimes only propagated in the first run of the main loops, not in prepare. If other modules are waiting for it they cannot enter their main loop. That's why all threads have to be started first, and only the it is waited for all of them to enter testable mode.

- removed ExceptionHandlingDecorator::setOwnerValidity()

- All accessors come up in exception state.
- Read-accessors increase counter in init phase

Assertion is gone, but tests still failing

  - EntityOwner has individual counters for both events
  - Adapted all instances of increment/decrementDataFaultCounter
  - Not changed getDataValidity() implementation yet
  - Tests failing

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

Need to wait until the internal fan out threads have been launched and acquired the testable mode lock before continuing with app starting and testing to avoid race conditions.

move ApplicationModule::appConfig() to ModuleImpl::appConfig() so it can also be used from ModuleGroup

Implemented first part of #17: A HierarchyModifier can now be specified instead of the eliminateHierarchy boolean flag. No new functionality is yet added.

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

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

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

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