rustdoc: Fix output coloring for doctest building & running

[fmease]

Follow-up to PR #148834 and issue #148749.

• Add a regression test for issue doctest errors are no longer colored #148749
  • we want to check that --color=auto (the default) is respected when rendering doctest build errors
  • we can't test that directly because the output streams are obviously redirected into golden files *.{stdout,stderr} by compiletest which isn't a terminal, so --color=auto becomes indistinguishable from --color=never
  • therefore I was thinking of utilizing CLICOLOR_FORCE=1 to indirectly detect auto working
  • however that's blocked on Diagnostic infra doesn't respect CLICOLOR_FORCE=1 #148864 unless we find another solution
  • ideally we could use compiletest's SVG test mechanism but it's unclear if it'll work out of the box for us (like rendering the STDOUT as an SVG, not STDERR)
  • if worst comes to the worst we'll have to persist the ANSI codes until compiletest is patched
  • the test would look something like:

    // EXPLAINER
    // issue: <https://github.com/rust-lang/rust/issues/148749>
    //@ compile-flags: --test --color=auto --error-format=human
    //@ rustc-env:CLICOLOR_FORCE=1
    //@ normalize-stdout: "finished in \d+\.\d+s" -> "finished in $$TIME"
    
    //! ```
    //! undefined
    //! ```
    

• Also run "color capability detection" for lexically / syntactically invalid doctests
  • if we fail to lex or parse the doctest, we construct a dummy doctest for which we currently unconditionally set supports_color to false for no apparent reason
  • that means we don't print syntax error diagnostics with colors by default which is bad
• In doctest::make::parse_source, run "color capability detection" on STDOUT by default not STDERR since we / libtest are outputting these diagnostics to STDOUT by default (as part of its normal output)
  • see also fix(rustdoc): Color doctest errors #148834 (comment)
  • this means rustdoc doctest.rs --test | cat still outputs colors STDOUT despite us piping STDOUT to a "non-terminal"
  • it also means that rustdoc doctest.rs --test 2>/dev/null outputs no colors to STDOUT despite STDOUT being a terminal
  • the current behavior is only correct for --no-capture (rustdoc: Tracking issue for command-line flag --no-capture #148116): rustdoc doctest.rs --test --no-capture -Zunstable-options 2>/dev/null correctly disables colors for STDERR where the diagnostics land
  • I don't think if rustdoc_options.no_capture { /* query STDOUT */ } else { /* query STDERR */ } is sufficient
  • that's partly because there's also --test-args --no-capture (i.e., libtest's non-capturing mode)
    • I don't actually know how they differ and why rustdoc has its own non-capturing mode
    • not only do we want to query STDERR if !no_capture, we basically also want to query STDERR if --test-args --no-capture (however scanning libtest's arguments would be super janky) so rustdoc doctest.rs --test --test-args --no-capture 2>/dev/null correctly suppresses colors for STDERR
  • do we actually want / need to query both output streams in certain cases? Maybe
  • cc Diagnostic infra doesn't respect CLICOLOR_FORCE=1 #148864 (comment)

[fmease]

cc @Muscraft in case you're interested in fixing some of these points :)