Wrap termcolor's color api

[KodrAus]

Noted in #72

The pub use termcolor::Color we released env_logger 0.5.0 with was a bad call.

This PR duplicates the termcolor::Color API in env_logger so breaking changes in termcolor can be managed with some gymnastics in env_logger.

If a new variant is added to termcolor::Color:

• Color::from_termcolor will return None until/unless we have a corresponding variant
• Color::FromStr will return Err::Unrecognized until/unless we have a corresponding variant

If termcolor drops the concept of Color completely then we have a little more work to do, but it should still all be manageable.

This will technically be a breaking change, since our ParseColorError isn't equivalent to termcolor::ParseColorError so you couldn't ? it and Color isn't equivalent to termcolor::Color, but pragmatically I think this is safe to make in a patch.

cc @BurntSushi @briansmith what do you think?

[briansmith]

I think this is a positive change.

My main motivation with this kind of change is eliminating the termcolor dependency or at least making it optional. This appears to be progress in achieving that. My more general motivation for this kind of change is eliminating complexity. IMO, rather than have a more complete color API in env_logger to avoid the termcolor dependency, it would be better to have a simpler API such that, if somebody chooses to enable the termcolor dependency, then they get the color API, but if they don't choose that dependency, then they just don't get the color API and all color parsing and whatever is just a no-op. In fact, I wish the API were different so that all the styling were only available through a Style API that is only available when termcolor is used, so that all styling code (not just colors) is avoided when no styling is wanted.

However, again, this is a positive change, even if I don't think it is optimal.

[KodrAus]

You're right, I think we can do things differently in env_logger with more freedom over the API next time we want to make breaking changes to env_logger.

This PR pulls in the complete API that's available now through pub use termcolor::Color, so we can make termcolor a private dependency in a patch.

I think the next incremental step would be to move all color and styling APIs into a submodule under fmt (even if it's just re-exported) so it'll be easier to conditionally exclude it.

[briansmith]

You're right, I think we can do things differently in env_logger with more freedom over the API next time we want to make breaking changes to env_logger.

This is a breaking change already, right? It is possible (perhaps unlikely) that somebody is already relying on the fact that env_logger::Color is the same type as termcolor::Color.

[KodrAus]

It is technically a breaking change. I looked through env_logger's public dependents using Color and none of them seem to depend on env_logger::Color and termcolor::Color being the same (we've never advertised Color as coming from termcolor). So I'm comfortable pushing it through as a patch with details in the release notes unless folks are deeply opposed, in which case it might be a while before we're ready to bundle it with other breaking changes.