doctest errors are no longer colored

[ShE3py]

/// ```
/// foo
/// ``` 
fn foo() {}

$ rustdoc --test lib.rs
---- lib.rs - foo (line 1) stdout ----
error[E0425]: cannot find value `foo` in this scope
 --> lib.rs:2:1
  |
3 | foo
  | ^^^ not found in this scope

error: aborting due to 1 previous error

On the +beta and +nightly channels, the stdout is no longer colored. Using --color=always fixes the issue.

Regressed in #147207 cc @Muscraft

---

@rustbot label +A-doctests +T-rustdoc +regression-from-stable-to-beta

[fmease]

Yeah, here's a deep analysis by me from a few weeks back of what's going on (#148101 (comment)):

[…]

However, since said PR (#147207: migrating coloring crates), HumanEmitter::supports_color() unconditionally(!) returns false (in fact, Emitter::supports_color is no longer used by anyone else and should be removed), so there's no reason to keep it. Rephrased, since that PR all compiler diagnostics for doctests are uncolored.

You could argue that I should keep it and patch supports_color in rustc to "work again". However, I'd rather rework our doctest coloring wholesale in a separate PR. At least before that migration PR, our setup was quite busted:

1. First of all, it didn't query+set supports_color for syntactically invalid doctests, so syntax errors were always shown without color (contrary to e.g., name resolution errors).
2. Second of all, calling supports_color() here was quite frankly wrong: Piping the output of rustdoc … --test into a file (or | cat or whatever) did not suppress colors. I'm not actually sure if we can ever address that nicely (without stripping ANSI codes after the fact) since we pass that diagnostic to libtest, right? I might very well be wrong here, maybe it's a non-issue.