feat: support NO_COLOR and FORCE_COLOR env vars

[samypr100]

Summary

Closes #3955

Adds explicit support to NO_COLOR and FORCE_COLOR via GlobalSettings.

The order, per specs is now NO_COLOR > FORCE_COLOR > color.

This PR is a backup plan pending rust-cli/anstyle#192.

Test Plan

Tested all cases locally for now; I didn't see existing tests for GlobalSettings parsing.

[codspeed-hq]

CodSpeed Performance Report

Merging #3979 will not alter performance

_{Comparing samypr100:adjust-color-settings (affba38) with main (40e0ddd)}

Summary

✅ 13 untouched benchmarks

[charliermarsh]

Should we add CLICOLOR_FORCE as well so that it's respected over the color CLI argument?

[charliermarsh]

I'm fine to merge this regardless of anstream changes.

[charliermarsh]

@samypr100 - This looks good to me. Ok to merge?

[bluss]

The way I read the examples on those two pages, https://force-color.org/ http://no-color.org/ they both suggest that command line flags that turn on color should have precedence over NO_COLOR. i.e "do getopt(3) and/or config-file parsing to possibly turn color back on" and so on. Not sure if I'm confusing myself, or if there are contradicting specs.

[samypr100]

@bluss They're examples, not the standard. The standard itself (the sentence at the top of the pages) doesn't go into detail on how they are meant to interact with each other.