Migrate unused-revision-names check from tidy to compiletest

[nilotpal-n7]

From what i understand, we need to migrate the check such that it executes before running the actual tests(revisions) as the runtest::run() assumes that theres no revision/unused-revision related issue.

Implementation/Logic:

1. Declared unused_revision_names in EarlyProps.
2. Parse unused_revision_names along side revisions in lib::make_test().
3. Check unknown/unused revision before returning the final collected test in lib::make_test()

(I initially thought to implement it in TestProps then execute it in runtest::run() but that would be too late).

Tests:

1. (./x test, saved the logs in a file, then grep the panic message) -> no error/panic found(related to this) -> means previous implementations passed.
2. (I tested it using intentional errors like; same revision in //@ revision and //@ unused-revision-names, unknown revision, and the wildcard "") -> emits corrects panic/error messages and skips all check for "" -> correct output

---

I've tried to keep its functioning as close to what it was in tidy as possible.

I'm not super sure if this is most optimal solution,
so any feedback on approach or potential edge cases would be very helpful.

---

Issue: #144671

[rustbot]

Some changes occurred in src/tools/compiletest

cc @jieyouxu

[rustbot]

r? @Zalathar

rustbot has assigned @Zalathar.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[rustbot]

This PR was rebased onto a different master commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

[rustbot]

Some changes occurred in src/tools/cargo

cc @ehuss

[rustbot]

⚠️ Warning ⚠️

• Some commits in this PR modify submodules.

  If this was not intentional, see I changed a submodule on accident in the rustc dev guide.

[Zalathar]

Somehow this PR has ended up including a bunch of submodule changes, making it unreviewable in its current state.

[Zalathar]

Given that the tidy check currently works fine, and considering the current state of compiletest directive handling, I don't think we should make this change at this time.

Adding more complexity to directive-handling code that is in dire need of major overhauls will only serve to make those overhauls even harder, without any significant benefit.

[jieyouxu]

I'm inclined to agree, getting directive handling code out of its current situation is a much higher priority. I don't want to introduce complications for cleanup efforts on that front in the short/medium term.

Thanks for the PR in any case.