bootstrap: Include feature-gated items in bootstrap tool docs

[Zalathar]

I noticed that the nightly-rustc docs for build_helper don't include the metrics module, because it's gated behind the non-default feature flag feature = "metrics".

This PR fixes that by using --all-features to document all features, and enabling rustdoc's #![feature(doc_cfg)] (via -Zcrate-attr) so that rustdoc will indicate which items require feature flags.

The first two commits are a general cleanup of tool_doc! to pull almost all of its non-trivial code out of the macro and into regular functions.

[rustbot]

r? @Mark-Simulacrum

rustbot has assigned @Mark-Simulacrum.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

Why was this reviewer chosen?

The reviewer was selected based on:

• Owners of files modified in this PR: bootstrap
• bootstrap expanded to 6 candidates
• Random selection from Mark-Simulacrum, clubby789

[Zalathar]

As a follow-up we could also enable this for compiler crates, since a few of them have feature flags to enable nightly-only features when they aren't being used by rust-analyzer.

[Zalathar]

I would also like to note that this would have been much more annoying without -Zcrate-attr.

[Zalathar]

I really want to blanket allow clippy::too_many_arguments and clippy::type_complexity across all of bootstrap, but I won't do that in this PR.

[Kobzol]

r? kobzol

Note that this will conflict a lot with #161716. In general I'm happy to see most of the code move out of a macro.

[Kobzol]

Aside: do you find the build_helper/bootstrap docs being present in the nightly rustc docs useful?

[Zalathar]

Aside: do you find the build_helper/bootstrap docs being present in the nightly rustc docs useful?

I use the nightly-rustc docs intermittently, but when I do reach for them it's nice to have everything there in one place, especially when I'm not at a computer and can't easily search the source.

[Zalathar]

Note that this will conflict a lot with #161716. In general I'm happy to see most of the code move out of a macro.

If conflicts are a concern, I can potentially cut this PR down to just the main fix (within the macro), and defer the macro-extraction to follow-up work.

(I had to do the extraction to work on the fix, but now that I have the fix it should be easy to backport to main.)

[Kobzol]

I'd perhaps either do that, or wait for the other PR to get merged, yeah.