coverage: Add enums to accommodate other kinds of coverage mappings

[Zalathar]

Extracted from #118305.

LLVM supports several different kinds of coverage mapping regions, but currently we only ever emit ordinary “code” regions. This PR performs the plumbing required to add other kinds of regions as enum variants, but does not add any specific variants other than Code.

The main motivation for this change is branch coverage, but it will also allow separate experimentation with gap regions and skipped regions, which might help in producing more accurate and useful coverage reports.

---

@rustbot label +A-code-coverage

[rustbot]

r? @petrochenkov

(rustbot has picked a reviewer for you, use r? to override)

[rustbot]

Some changes occurred to MIR optimizations

cc @rust-lang/wg-mir-opt

[oli-obk]

I don't think this will work with variants that have multiple terms unless all of them are slices and you use https://doc.rust-lang.org/std/slice/fn.from_ref.html here (in which case you could proabably return a slice instead of an iterator)

But also not important, you can refactor to make it work when you add more variants

[Zalathar]

All of the variants supported by LLVM have exactly zero, one, or two terms.

So my plan is to eventually change this definition to something like:

let one = |a| [Some(a), None].into_iter().flatten()

That way the individual arms that use one won't have to change.

(But I won't bother doing this until I actually add a variant that requires 0 or 2 terms.)

[oli-obk]

@bors r+ rollup

[bors]

📌 Commit 124fff0 has been approved by oli-obk

It is now in the queue for this repository.

[Zalathar]

After some quick experiments, I'm sad to report that LLVM's gap regions appear to be unusable.

LLVM documentation suggests that they work like code regions, except that code regions always take priority over gap regions when determining line counts.

In practice, that's not accurate. For example, replacing all of our code regions with gap regions ought to have no effect on the resulting coverage reports, but in fact it causes some (but not all) of our line counts to disappear, for reasons that I haven't fully determined. (For example, gap regions that span across multiple lines appear to be handled differently.)

I suspect that the llvm-cov reporting tool is making a lot of undocumented assumptions about how clang uses gap regions, and without understanding those assumptions we probably can't predict how it will handle gap regions that we try to emit.