Add the known-bug test directive, use it, and do some cleanup

[jackh726]

cc rust-lang/compiler-team#476

Now tests can be annotated with known-bug, which should indicate that the test should pass (or at least that the current output is a bug). Adding it relaxes the requirement to add error annotations to the test (though it is still allowed). In the future, this could be extended with further relaxations - with the goal to make adding these tests need minimal effort.

I've used this attribute for the GAT tests added in #93757.

Finally, I've also cleaned up header.rs in compiletest a bit, by extracting out a bit of common logic. I've also split out some of the directives into their own consts. This removes a lot of very similar functions from Config and makes TestProps::load_from read nicer.

I've split these into separate commits, so I in theory could split these into separate PRs if they're controversial, but I think they're pretty straightforward.

r? @Mark-Simulacrum

[Mark-Simulacrum]

r=me with or without the nit applied, depending on how you feel about it.

[jackh726]

@bors r=Mark-Simulacrum

[bors]

📌 Commit 36cf48b has been approved by Mark-Simulacrum

[petrochenkov]

I didn't notice this PR soon enough, but this is a mistake, IMO.
//~ ERROR annotations make exactly the same sense and serve the same goals in "bug" tests as in any other tests - they are useful for human reader, and prevent human mistakes during test writing by providing redundancy.

[jackh726]

@petrochenkov there was some discussion on zulip about this, but let me try to summarize what I can recall:

In regular tests, //~ ERROR can help by providing redundancy (I'm not fully convinced that they do). Importantly though, this redundancy is that the error message you expect matches the error message you get. In known-bug tests, we don't expect any error message. It doesn't make sense (at least to me) to add error annotations to a test that you expect to be different (compile, or fail with different error). Another reasonable argument, for example, would be that the error annotations are for the errors you expect; so if you expect the test to compile, you shouldn't see any error annotations.

On the contrary, keeping the stderr around does help, because it provides a "history" of why the test did not compile. If a test starts to pass, it helps you understand why and what changed.

[petrochenkov]

In practice this makes tests hard to read and write for me, so I'm currently just asking people to avoid // known-bug if I encounter it during review (#97391 (comment)), and not using it myself.

[petrochenkov]

In the linked issue I wanted to see where the bug is exactly, and what the bug is exactly, which is hard to do if the errors are in a different file and that file has lines anonymized, especially if the test gets larger than a few lines.