Break query cycles without spawning a separate thread

[zetanumbers]

This PR removes separate thread for query cycle breaking. Essentially I made sure that behavior right before a block is done before deadlock handler is called.

TODO: explain in a comment that we use CurrentGcx in case worker thread no longer has any tasks to execute and triggers a deadlock handler, which means there's no ImplicitCtxt set to extract tcx from.

While this code is very unpolished at the moment and introduces some test failures due to diagnostics, it's a proof of concept and a place for feedback. I plan to make query cycle handling blocking of all worker threads in order to add something like a WorkerLocal::as_deadlocked to return every worker-local value in future. This is one of the stepping stones to remake query state hash table with QueryJob's into something more worker-thread-local.
Blocked on #155881.

[rustbot]

r? @jackh726

rustbot has assigned @jackh726.
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

Why was this reviewer chosen?

The reviewer was selected based on:

• Owners of files modified in this PR: compiler
• compiler expanded to 73 candidates
• Random selection from 21 candidates

[zetanumbers]

r? @nnethercote

[rustbot]

This PR was rebased onto a different main 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.

[Zoxc]

The structure I had in mind: wait_on loops until mark_blocked no longer detects a deadlock. When it does detect a deadlock, it directly calls break_query_cycle which is changed to return the waiter to wake up. It returns if it is the waiter to wake or otherwise wakes the right waiter then continues the loop.