rustdoc features doctests conditional on cfg or target feature but that's not RFC'ed, not tested, not really documented and somewhat broken

Uplifted from https://github.com/rust-lang/rust/pull/138907#discussion_r2371927098. While reviewing https://github.com/rust-lang/rust/pull/138907 I found out that rustdoc intentionally skips[^1] doctests if the #[doc(cfg(…))] (unstable feature doc_cfg, #43781) or #[target_feature(enable = "…")] (stable) on the owning item doesn't match[^2].

E.g., rustdoc file.rs --test doesn't execute any tests where file.rs:

#![feature(doc_cfg)]

/// ```
/// assert!(true);
/// ```
#[doc(cfg(spec))]
fn f() {}

running 0 tests

test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

but also notice the "0 ignored". Passing --cfg spec executes the doctest:

running 1 test
test t.rs - f (line 3) ... ok

test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

Similarly:

/// ```
/// assert!(true)
/// ```
#[target_feature(enable = "feat")]
fn f() {}

running 0 tests

test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

because rustdoc treats #[target_feature(enable = "…")] as a #[cfg(…)] for all practical matters.

While that seems like a nifty feature, it's also a bit surprising and undiscoverable! Moreover, the #[doc(cfg(…))] part is not part of RFC 3631 and I believe the #[target_feature(enable = "…")] part was accidentally "stabilized" / "leaked on stable" in one of the PRs implementing doc_cfg (however I've yet to verify the latter claim).

It is briefly mentioned in the rustdoc book in the unstable features chapter: https://doc.rust-lang.org/rustdoc/unstable-features.html#doccfg-recording-what-platforms-or-features-are-required-for-code-to-be-present.

However, there don't seem to be any tests for this "feature" (I removed the logic and ran tests/{rustdoc{,-ui},run-make} and nothing failed).

Re. "somewhat broken": As alluded to, libtest shows "0 ignored" if the doctest is skipped. That's because rustdoc straight up doesn't consider the item testable and doesn't process the doctests at all! I'm not sure if others would consider that broken or a good feature / logical consequence. I need to think about that.

[^1]: I.e., not in the libtest's "ignored" sense.
[^2]: I have no idea what that means for target features which I'm personally not really familiar with. E.g., my question is: Does a #[target_feature(enable = "…")] "ever match"?

Start by reproducing the rustdoc doctest behavior for #[doc(cfg(...))] and #[target_feature(...)] described in the issue. Review the rustdoc unstable-features documentation, RFC 3631, and the tests under tests/{rustdoc,rustdoc-ui,run-make}; removing the logic reportedly causes no failures. Done means the behavior is specified, documented, and covered by tests, including the skipped-test reporting question.