Allow disabling text colors

[Shrews]

Allows control of when builder output text is colorized.

Honors the NO_COLOR and FORCE_COLOR environment variables.

Fixes #716

[nitzmahone]

Overall looks okay, though I'd question if it warrants a dedicated CLI arg- for most things we guard that kind of addition pretty carefully.

I'm also curious how hard it is to get the build output to include color codes- my worry is that having this option could set an expectation that we're going to also filter or otherwise force-disable generation of color codes from the build, which could be problematic.

[Shrews]

Overall looks okay, though I'd question if it warrants a dedicated CLI arg- for most things we guard that kind of addition pretty carefully.

Ack. I can remove that bit.

I'm also curious how hard it is to get the build output to include color codes- my worry is that having this option could set an expectation that we're going to also filter or otherwise force-disable generation of color codes from the build, which could be problematic.

Not sure I catch what you mean here...

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[webknjaz]

@Shrews there's a corner case in Rich interpreting FORCE_COLOR as "also produce ANSI-sequences for bold" with NO_COLOR as "only disable color-related ANSI but not bold".

This resulted in us settling on an additional variable TTY_COMPATIBLE that only supports 1 or 0 explicit values (auto-detect otherwise): Textualize/rich#2924 (comment) / Textualize/rich#3675.

I'm wondering if this PR would benefit from also consulting that var.

Also, here's how termcolor handles these vars (it doesn't yet look into TTY_COMPATIBLE tho): https://github.com/termcolor/termcolor/blob/fd08149/src/termcolor/termcolor.py#L92-L125. In general, I think it'd be beneficial closely following whatever logic widely-used libs implement.