Fix spinner-tqdm output conflict and refactor stream reading

[OutlyingWest]

Summary

This PR addresses issues with animation display when using tqdm in conjunction with PyTorch and Score-P logging.

Problems Fixed

1. Spinner animation worked with the PyTorch progress bar (tested in examples/gpt-demo/demonstrator.ipynb), but was broken with the default tqdm.

2. When scorep_jupyter_DISABLE_PROCESSING_ANIMATIONS=1 is set, spinner output overlapped with tqdm.

Changes Made

1. Refactored reading of Score-P process streams: both stdout and stderr are now read in chunks using separate threads.

2. Stream reader threads now wait on a shared threading.Event that signals the termination of the process_busy_spinner animation when scorep_jupyter_DISABLE_PROCESSING_ANIMATIONS=0.

3. Added a is_multicell_final=True flag as a scorep_execute() function argument to suppress spinner creation during %%finalize_multicellmode when scorep_jupyter_DISABLE_PROCESSING_ANIMATIONS=0. This ensures create_busy_spinner() produces a dummy spinner without capturing the event.

Notes

• Fix ensures tqdm works with both PyTorch and default modes.

• When scorep_jupyter_DISABLE_PROCESSING_ANIMATIONS=0 is set (animation is enabled) - no Score-P child process stderr output in console during animation. In other words, if user's code in cell raises an exception - no detailed error message is seen but only error log is captured. This behavior is described in README.md

[elwer]

what exactly is the purpose of the multicellmode_timestamps in the current version? In the past, we used them to visualize the different cells in the diagrams for coarse-grained measurements, e.g. CPU utilization. Since this was outsourced to ipython extension, I am not sure if we need the multicellmode_timestamps in the current version. I guess, you are disabling the spinner in case multiple cells should be tracked by Score-P (multicellmode) but perhaps, we do not need the timestamps anymore but just a flag for that case, right?

[OutlyingWest]

Yes, We do not need multicellmode_timestamps there anymore. I removed them in the last commit #45. Regarding a flag, you are right, it is still necessary to suppress spinner animation in case of %%finalize_multicellmode command execution

[elwer]

Can we have a central definition for "True" values that we can use everywhere for checking the env variables?
e.g.
common.py
TRUTHY_VALS=['true', '1', 't']

somewhere in the code:
is_enabled = os.getenv("SCOREP_JUPYTER_DISABLE_PROCESSING_ANIMATIONS").lower() in TRUTHY_VALS

[OutlyingWest]

For this I'd suggest implementing something similar to Django-style settings.py. Since we already have a number of environment variables (e.g., flags, paths to results, SCOREP_ variables, etc.) and are likely to introduce many more in the future, it makes sense to define a central configuration file - not just for flags, but for all project settings.

The benefits of this approach:

• All settings can be shared across all parts of application (e.g. kernel, extensions)
• Environment variables and other settings are defined and parsed only once - in a single place: settings.py.
• No more repetitive os.getenv(SOME_VAR) calls scattered throughout the codebase - just from conf import settings and settings.SOME_VAR to access any variable.
• (Optional) Extend settings.py by logging config so we would have full configuration and control on our project in one place.

Finally (if needed) it can be extended to:
conf/
└── settings/
├── init.py - to choose between environments (prod - chosen by default with env var)
├── test.py - for unit tests (animations suppressed, SCOREP_* configured for tests, logging.DEBUG = True)
├── dev.py - e.g. logging.DEBUG = True by default
└── prod.py - e.g. logging.DEBUG = False