* Not implemented yet. Currently always return false.
* Test exists and compiles, but is failing due to the missing implementation.

Paths starting with "/" will be stripped of the leading slash now. Empty paths (or a single slash) will be interpreted to refer to the Module itself and hence return *this.

This logic is otherwise ofter required in code which uses submodule().

Before it had to be stripped for all use cases anyway, so it is better to leave it out from the beginning.

so dependencies can already ask for the new features

It was handing out only those control system accessors which do *not* belong to the particular ControlSystemModule, because the if condition was inverted.

This function is indented for direct use when creating a HierarchyModifyingGroup, where this behaviour makes more sense. A "." as name of a HierarchyModifyingGroup will be the equivalent to HierarchyModifyer::hideThis.

For some reason this was disallowed and even tested to throw.

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

This might have led to test stalled exceptions despite the test did not yet even start properly.

Co-authored-by: Jens Georg <jens.georg@desy.de>

This needs to be done here since the recent changes in DeviceAccess, see comment for reason.

If a circular dependency was checked and the dependent module was not
yet in the waitMap, the lock was never released.

Print path to the nonvirtual module if oneLevelUp or oneUpAndHide are
detected directly below the applicaiton root.

This reverts commit a80ebc2d.

This was the wrong approach, see ChimeraTK/DeviceAccess-DoocsBackend#45

This helps understanding where an error is coming from, e.g. when multiple devices are used in the same logical name mapped device

This greatly helps debugging real setups, as the messages will usually end up in the server log.
Note: Ideally, a proper logging mechanism should be used instead, but this does not yet exist!

remove unnecessary and wrong (not thread safe) increment+decrement of the testableMode_deviceInitialisationCounter

this fixes #194