Feature & Bug fix: Logging overhaul

[fehret]

• Please check if the PR fulfills these requirements

• New and existing unit tests pass locally with my changes
• Tests for the changes have been added (for bug fixes/features)
• Docs have been added / updated (for bug fixes / features)

• What kind of change does this PR introduce? (Bug fix, feature, docs update, ...)

• Feature: New log level to only show training-related information to make output from parameter sweeps more easily readable
• Bug fix: No more double output in non-Slurm environments (also mentioned in Duplicated output when running from CLI #13)

• What is the current behavior? (You can also link to an open issue here)
  Currently there is duplicated output of all information, when running from terminal and Jupyter notebook. And every run prints the full configuration, Rank information etc. which is not necessary in cases of parameter sweeps for example.

• What is the new behavior (if this is a feature change)?
  User can set a log level vie the --log-level CLI flag, with quiet being the one that corresponds to the aforementioned mode.
  This information then gets parsed directly in run.py, via a custom function, because logging is used before the regular parsing. The command and options do show up in the --help screen.
  When set to quiet, only the information related to the training, i.e. epoch numbers and metrics, are logged to the terminal.
  STDERR is logged to both the terminal and a file, without logging things multiple times.

• Does this PR introduce a breaking change? (What changes might users need to make in their application due to this PR?)
  Not changes necessary, the standard behavior is exactly as before.

• Other information:

[fehret]

NOTE

The HPO stuff is not yet included in this, but I still wanted to open the PR to give you a chance to look at everything before.
Especially the early parameter parsing feels a bit suboptimal, any remarks/ideas?

[ikanher]

I think the early parameter parsing is ok, I'm not really seeing a better way to do it.

Can you please make a separate pull request for fixing #13, the log.propagate = False seems to be to key to this fix.

About the progress/metrics logging, I'm not a big fan of introducing a new metrics log-level. Here https://discuss.python.org/t/setting-log-level-based-on-quiet-debug-flags/55570 they seem to have the idea of adding a quiet log-level instead that you can enable to suppress messages. Maybe something like this could work instead of suppressing them by default?

About the code in general, I'm not sure why we would need a class _TeeStream for this (and what it's doing herem even if being familiar with the Unix tee command). Could we maybe use logging filters (https://docs.python.org/3/library/logging.html#filter-objects) to achieve the same?