enhance log color detection and default to colored logs in docker

[markope]

Support NO_COLOR/FORCE_COLOR environment variables for log output

Description

This PR improves log color detection to support standard environment variables and provide better defaults for containerized environments.

Changes

• Add support for NO_COLOR environment variable to disable colors (no-color.org)
• Add support for FORCE_COLOR and CLICOLOR_FORCE environment variables to enable colors
• Default to enabling colors in non-TTY environments (e.g., Docker containers)

Motivation

When running crossbar in Docker or other non-TTY environments, log colors were always disabled because sys.__stdout__.isatty() returns False. This made logs harder to read when viewing via docker logs or in CI/CD systems that support ANSI colors.

Usage

# Force colors on (useful in Docker/CI)
FORCE_COLOR=1 crossbar start

# Force colors off
NO_COLOR=1 crossbar start

# Auto-detect (default) - now enables colors even without TTY
crossbar start

Breaking Changes

Minor: Logs in non-TTY environments will now show colors by default. Set NO_COLOR=1 to restore previous behavior.

Checklist

• Code follows project style guidelines
• Changes are minimal and focused
• No new dependencies added

[markope]

Fixes #2150

[oberstet]

Fixes #2150

1. there is no issue 2150 - the correct issue is [FEATURE] Support standard color control environment variables. Use colored logs by default in docker contexts. #2149
2. PRs MUST contain audit files, look at https://github.com/crossbario/crossbar/blob/master/.audit/oberstet_modernization-phase-14.md?plain=1 which relates the PR Modernization phase 1.4 #2145 to the issue Phase 1.4: Packaging Tool Modernization #2144
3. this should be noted in https://github.com/crossbario/crossbar/blob/master/CONTRIBUTING.md - but it is currently not, so that is a docs bug!
4. this will be checked in CI/CD - including the cross-referenced issue - but it is currently not yet - so that's another CI/CD bug!
5. the PR runs into code-quality / formatting issues, which you can check locally (recommended!):

oberstet@amd-ryzen5:~/work/wamp/crossbar$ just check-format
==> No venv name specified. Auto-detecting from system Python...
==> Defaulting to venv: 'cpy312'
==> Creating Python virtual environment 'cpy312' using cpython-3.12 in ./.venvs/cpy312...
Using CPython 3.12.12
Creating virtual environment with seed packages at: ./.venvs/cpy312
 + pip==25.3
Activate with: source .venvs/cpy312/bin/activate
==> Successfully created venv 'cpy312'.
Python 3.12.12
pip 25.3 from /home/oberstet/work/wamp/crossbar/.venvs/cpy312/lib/python3.12/site-packages/pip (python 3.12)
==> Activate Python virtual environment with: source ./.venvs/cpy312/bin/activate
==> No venv name specified. Auto-detecting from system Python...
==> Defaulting to venv: 'cpy312'
==> Installing package development tools in cpy312...
Python 3.12.12
...
==> No venv name specified. Auto-detecting from system Python...
==> Defaulting to venv: 'cpy312'
==> Linting code with cpy312...
warning: Invalid rule code provided to `# noqa` at src/crossbar/shell/app.py:199: W503
warning: Invalid rule code provided to `# noqa` at src/crossbar/shell/app.py:200: W503
All checks passed!
oberstet@amd-ryzen5:~/work/wamp/crossbar$ 

the just recipes are exactly what github actions uses as well!