Fix NO_COLOR convention regression

[nel]

Summary

NO_COLOR is a de-facto convention for disabling ANSI color output. The convention is presence-based: if NO_COLOR is present and non-empty, color should be disabled regardless of the specific value.

Reference:

• https://no-color.org/
• Archived copy: http://web.archive.org/web/20260616201813/https://no-color.org/

oha used to accept this convention, but since the --no-color clap/env wiring change it now parses NO_COLOR as a strict boolean. As a result, the common form NO_COLOR=1 now fails during argument parsing:

NO_COLOR=1 oha http://127.0.0.1:9 -z 1s -c 1 --output-format json --no-tui

invalid value '1' for '--no-color'
[possible values: true, false]

This PR restores convention-compatible NO_COLOR handling.

Behavior

After this change:

• unset NO_COLOR does not disable color
• empty NO_COLOR= does not disable color
• non-empty NO_COLOR, including NO_COLOR=1, disables color
• NO_COLOR=true disables color
• NO_COLOR=false disables color
• --no-color continues to work

Compatibility note

Restoring the NO_COLOR convention means this is technically a behavior change for NO_COLOR=false.

With the recent strict boolean parsing, NO_COLOR=false meant “do not disable color”. With convention-compatible parsing, NO_COLOR=false disables color because the variable is present and non-empty.

Users who want color should unset NO_COLOR or set it to an empty value.

Tests

Added coverage for:

• NO_COLOR=1
• empty NO_COLOR=
• NO_COLOR=true
• NO_COLOR=false
• --no-color

Ran locally:

• cargo test no_color -- --nocapture
• cargo fmt --all --check
• cargo clippy --all-targets -- -D warnings