ScriptedInitialisationHandler: catch boost exceptions and throw ChimeraTK logic_error with improved what() message

The message of this exception is usually lost and the user is left with
an obscure error about not calling shutdown() in the constructor without
any clue what was wrong with the config

The new order has the following advantages:
- values 0=OK and 1=Fault are compatible with frequent use of booleans like "is_error"
- values are matching ("accidentally") the DOOCS convention

- introduce StatusOutput class
- rename ChimeraTK::States enum to ChimeraTK::StatusOutput::Status and make strongly-typed
- introduce reserved tags to detect StatusOutputs to be aggregated

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

* Fix initial msg. Add automatic connection to the LoggingModule.

Now the Logger is a VariableGroup and in the prepare() method an empty
msg is written once. This makes sure the LoggingModule is not waiting
for initial values of Loggers and messages by other Loggers get lost.

* Add message in case on modules with Logger are found.

* Fix test and remove implementation of removed method.

* Do not use hard coded tags but use default tags.

Now all tags given to the LoggingModule are used to look for senders.

The user can now also choose to publish messages only to the control
system.

Refactored.

Reading was done only in deeper levels inside the VariableGroups.

See 1af92147. Input accessors are now properly part of the ReadAny group which improves the deterministic behaviour.

This provides a strict guarantee for the order of updates w.r.t. trigger, especially for tests.

  - Removed extra call to registerModule which caused multiple creation
    of the same module on a tree node
  - Made addChildNode private

Instead of holding the modules in a flat list as before, this represents
the ownership of nested modules correctly and prevents possible memory
access violation on destruction.

Currently does not get the modules in a way that they can be downcasted
to test if StatusMonitor, etc

Correctly navigate to parent module via virtual path.