Encourage colored-output common practices

[epage]

Providing a default path for getting people to follow common practices

• Will help encourage people to do so
• Ensure people consistently implement the semantics (including precedence levels)

Common practices include:

• NO_COLOR support
• CLICOLOR / CLICOLOR_FORCE support
• Basic or advanced truecolor support detection
• TERM=dumb checks
• TTY detection
• Ensuring people call enable_windows_ascii and disable color when it fails
  ---color=<always|auto|never>

Since the CLI arg would involve integrating with another crate in the public API (like structopt / clap3), unsure whether that should be left to another crate to avoid coupling their breaking changes to yansi's.

[SergioBenitez]

As with #20, I don't think these decisions should be up to yansi.

Ensuring people call enable_windows_ascii and disable color when it fails ---color=<always|auto|never>.

I do think we should automate this, however. I've opened #25.

[epage]

To be clear, I wouldn't put this directly in yansi but a yansi-detect or clap-yansi crate. People can opt-in as they wish, depending on the crate, calling the initialization, and filtering their color palettes accordingly but having a default policy to get people up and running on best practices is a big ergonomic win and developing the two together is also a big help for users.

[SergioBenitez]

I'm happy to support any efforts technically, but I have no opinion on which standard/policy users should follow.