tty: treat empty NO_COLOR same as absent NO_COLOR

[aduh95]

As specified in https://no-color.org/, setting the env variable to an empty string should result in that env variable to be ignored:

Command-line software which adds ANSI color to its output by default should check for a NO_COLOR environment variable that, when present and not an empty string (regardless of its value), prevents the addition of ANSI color.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 90.21%. Comparing base (a36981a) to head (59fbe0d).
Report is 3 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main   #58074      +/-   ##
==========================================
- Coverage   90.21%   90.21%   -0.01%     
==========================================
  Files         630      630              
  Lines      186391   186391              
  Branches    36608    36608              
==========================================
- Hits       168161   168150      -11     
- Misses      11052    11061       +9     
- Partials     7178     7180       +2     

Files with missing lines	Coverage Δ
lib/internal/tty.js	99.15% <100.00%> (ø)

... and 25 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[BridgeAR]

These entries could (IMO should) all be simplified by just checking for truthiness. An env may only be undefined or a string due to the internal setter, no matter that e.g., null is assigned. It would result in 'null'.

[BridgeAR]

Thinking about it again: a user may pass through arbitrary values as environment variables. If a zero would for example be passed through, it would now be handled as not defined, while it would be picked up as process.env (being transformed to a string before).

So maybe we should just handle it as the stringified version? As in: env.FOO?.toString()? I am somewhat indecisive about how to handle this case ideally.

[aduh95]

@BridgeAR is it semver-major or just a fix? Wdyt about not landing it on LTS release lines to minimize the risk of ecosystem breakage, but still land it on Current release line?

[BridgeAR]

@aduh95 I think it's fine to land it on 24 or do you mean any release before?