compiletest: Support optional error annotations

[petrochenkov]

that are not required to annotate an actual error, which is sometimes useful for target-dependent errors.

The syntax is //~ ERROR? message.

This is sort of a low cost low benefit feature, that is useful in specific cases.
I think it's better to have it, but not having it would also be ok.
The specific syntax is also up to debate.

r? @jieyouxu

[rustbot]

The rustc-dev-guide subtree was changed. If this PR only touches the dev guide consider submitting a PR directly to rust-lang/rustc-dev-guide otherwise thank you for updating the dev guide with your changes.

cc @BoxyUwU, @jieyouxu, @Kobzol

Some changes occurred in src/tools/compiletest

cc @jieyouxu

[jieyouxu]

I'm hesitant to support optional error annotations in this fashion (as opposed to not requiring exhaustive error annotations with an explicit opt-in), for a few reasons:

1. If these "optional" (or somehow condition-dependent) errors are not important for test intention, I think not requring exhaustive error annotations is the better choice. Making these kind of errors optional but still show up in error annotations to me seems like distractions from the "important" errors w.r.t. test intention.
2. I'm slightly concerned about the potential for misuse of this feature. In that, it seems quite easy to accidentally let through errors that we shouldn't be emitting, or accidentally missing errors that we should be emitting, for the given conditions. There's also only a ?-character difference, so this seems easy to miss in reviews/authoring too.
3. I think we should identify why these errors are "sometimes"-only. Then see for instance:
   • Can the test be modified in a way without loss of test intention, such that the "unimportant" error isn't target-dependent, or doesn't get emitted at all?
   • Should a test be gated w.r.t. some capability/target/target arch/target env, if it's not important to test intention?
   • Or, should we simply have the error be ignored under dont-require-error-annotations if it's not important re. test intention?

I'm playing around w/ point (3) in #140588. Let me get back to you after playing around with the example tests changed in this PR.

[petrochenkov]

Okay, I agree it's easy to misuse and some of the cases should be fixed in the compiler (especially tests/ui/debuginfo/debuginfo-type-name-layout-ice-94961-2.rs) and others could maybe addressed by splitting into two tests.

We just need to not forget to remove the FIXMEs if that doesn't work out.