Support NO_COLOR and FORCE_COLOR env variables for color enabling/disabling

[G-Rath]

Is your feature request related to a problem? Please describe.
I'm switching over to this library from another, as it's both smaller and uses the idiomatic Sprintf pattern which means my IDE provides help around substitutions and tokens.

However, now color is always enabled regardless of if the terminal supports it or if common variables like NO_COLOR and FORCE_COLOR are set.

Describe the solution you'd like
I'm not super well versed on the differences between control codes, terminals, feature support, etc beyond knowing it's generally not as easy as calling e.g. os.doWeSupportColor, but my understanding is that NO_COLOR and FORCE_COLOR env variables are supported by a lot of software so at least checking for those would be great.

The previous library also checks if the code is being run in a terminal (vs a subprocess), and if TERM is (not) set to dumb, which sound reasonable to me.

Describe alternatives you've considered
I should be able to handle this within my codebase, but that feels a bit sad given for everything else I can just do NO_COLOR=1 and away we go.

Additional context
I'm happy to have a go at a PR for this, at least for the first two variables.

Personally I ran into this because I'm working on a CLI which has snapshot-based tests for its output which previously wouldn't have the color codes as in that context it's not running in a terminal - while there are valid arguments to be made that having color disabled in that context means the tests are not as real-life, there's also valid arguments around the readability of those tests when they've got control codes throughout them which is why having the ability enable and disable color via env variables I think is a good idea.

[jedib0t]

Great point! Will try to honor those environment variables soon. For now, you can use text.DisableColors().