Monitor mode

[ArneTR]

This PR adds the monitor mode which was originally brought in as idea from @davidkopp in this PR https://github.com/green-coding-berlin/green-metrics-tool/pull/556

The monitor mode sets the GMT in an endless loop where the providers continue to collect data.

Main change is that providers that do not collect system metrics but rather transient data like container metrics need an auto discovery mode.

This has in this PR draft so far been implemented for the CpuUtilizationCgroupContainerProvider.

Currently the other phases show as blank, but they will be removed in a future versions: https://metrics.green-coding.berlin/stats.html?id=b3527cc8-c17d-4284-95c4-aa4f353682fa

Caveats / TODOs:

• Currently the monitor mode is ended through a SIGINT (CTRL+C). If used in production it should not react to SIGHUP and also properly terminate on SIGTERM
• The GMT gets confused when monitor runs are compared. This has to be guard-claused.
• Untested how the tool behaves when left logging for 24 hours. This was not the actual design case of the monitor mode but people might use it in that form. TBD
• The implementation for the container discovery is done with a native linux cgroup implementation.
  • Advantages: Extremely performant
  • Disadvantages:
    • Since docker API is not used the names for the containers are unknown
    • We cannot scan containers under macOS

For docker name problem one could argue that a hashmap can be used where the already known containers are kept in so that lookups are kept to a minimum. However bringing a hashmap into the C code is quite some work and will create some overhead.

For the macOS problem: This is also already the case with the GMT. However what we could actually do is enter the VM and inject a script. Entering the VM via a tty is possible like so: stty -echo -icanon && nc -U ~/Library/Containers/com.docker.docker/Data/debug-shell.sock && stty sane

Leaving this as a point of discussion ...