Inlining `-Cinstrument-coverage` code into a uninstrumented crate causes problems

-Cinstrument-coverage is a per-crate setting, which makes it possible for instrumented and uninstrumented crates to be mixed during compilation.

This must be supported to some extent, because the standard libraries are built without coverage instrumentation, and instrumenting them would be unwanted in most cases. And we would also like to support instrumenting a project without instrumenting its dependencies, though cargo currently doesn't have a good way to actually set different rustflags for dependencies. Fortunately, inlining uninstrumented code into an instrumented crate mostly works, though in some cases it might end up being unexpectedly instrumented.

The more difficult case is when instrumented code gets inlined into an uninstrumented crate. This is an unusual configuration, but it can occur in practice, e.g. when building doctests as in https://github.com/rust-lang/rust/pull/132395#issuecomment-2449638516. When this happens, two problems can arise:

• Inlined MIR might contain StatementKind::Coverage statements, despite the current crate being built without coverage instrumentation. When codegen sees coverage statements, it cannot assume that coverage instrumentation is enabled.
• If the inlined code isn't instrumented, then executing it won't increase coverage counts, despite its original crate having been built with instrumentation.

For now, the workaround is to quietly discard any coverage statements that make their way into an uninstrumented crate. This avoids the ICE seen in #132395, but doesn't solve the problem of that code not being instrumented as a result.

Start with the doctest-building scenario referenced in the comment on #132395, then trace how inlined MIR containing StatementKind::Coverage is handled in an uninstrumented crate. Compare the current workaround of discarding coverage statements with the two reported failures: avoiding the ICE and preserving coverage counts for inlined instrumented code.