TerminalLogger (and Console Logger) should support explicit toggling of colorization

### Summary

We already have a way to disable/manage 'live' output of the TerminalLogger, but we should have a similar mechanism for explicitly controlling the use of color in our outputs.

We should support
* an explicit terminal logger parameter to control colorization: `-tlp:use_color=[true|false]` for terminal logger, `-clp:use_color=[true|false]` for console logger
* implicitly support `FORCE_COLOR` to make the use of color mandatory.
* [`FORCE_COLOR`](https://force-color.org/) is an emerging standard for communicating to terminal-output-writing applications that they should use colorization regardless of whatever detection they are using. This is comparable to `NO_COLOR`, just negated. I've logged https://github.com/dotnet/runtime/issues/124091#issuecomment-3860992479 to track the Runtime adding support in some of their usages of this standard, but we should also support it.
* implicitly support `NO_COLOR` to make the use of color forbidden

Precedence:
* NO_COLOR should supersede FORCE_COLOR
* an explicit `-tlp:use_color` or `-clp:use_color` should supersede any environment variable usage
* if multiple `-tlp` or `-clp` overrides are provided, last-one-wins as usual

### Background and Motivation

Scenarios like `dotnet watch` or other orchestrators where we aren't in control of our output stream, but users still deserve a nice UX

### Proposed Feature

Instead of just checking `Console.IsOutputRedirected`, we should see if `FORCE_COLOR` is set to anything. If it is, then we should emit colorized output. This _does not_ mean that we should emit _interactive_ output - only colorized output.

### Alternative Designs

_No response_