compiletest: FileCheck-based tests conflate FileCheck prefixes with compiletest revisions

Auto-registering revision names as check prefix is a bit sketchy, and that having to pass --allow-unused-prefix is an unfortunate side-effect of not knowing whether the test author actually wanted revision-specific check prefixes or not.

-- https://github.com/rust-lang/rust/pull/134463#discussion_r1890184927

With the current scheme where compiletest //@ revisions imply FileCheck prefixes of the same names, we can't distinguish between whether the author wanted to:

1. Use compiletest revisions but ONLY for compiletest directive purposes.
2. Use compiletest revisions but ONLY for filecheck prefix purposes.
3. Use compiletest revisions for BOTH purposes.

We might want to investigate splitting these orthogonal concepts and have something like //@ filecheck-prefixes: XXX register FileCheck prefixes separately.

Marked as E-hard as this will take quite a bit of investigation/design, and E-tedious as this probably involves updating a whole bunch of tests, and I don't have the bandwidth to mentor.

Start by investigating compiletest's current handling of //@ revisions and how those names become FileCheck prefixes. Review the linked discussion and representative tests to define the separate directive semantics, then identify the tests requiring updates. Done means the two concepts can be used independently without requiring --allow-unused-prefix as a workaround.