After discussion with Martin K. we concluded that this monitor makes no sense. Legit cases should use the ExactMonitor
instead (if e.g. a boolean on/off configuration switch is to be observed). The monitoring of a Status value makes
no sense, since we would then have a monitor monitoring another monitor. In that case, the behaviour of the other
monitor should either be corrected, or the monitors should be aggregated with the right aggregator mode.

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

    - Basic structure of test application
    - Added modules
    - Refactoring of StatusMonitor to provide a non-templated base class
    - Needs follow-up, for status see issue #14 and the linked follow-up
      ticket

- worked around gcc bug buy adding a useless default constructor
- removed dangerous convenience referene which would be broken by copy constructor and assignment operator

- removed sleep
- put reading to end of loop (process initial value before blocking)