Fix post-monomorphization error note race in the parallel frontend

[xmakro]

Fixes #154260.

collect_items_rec decides whether to attach the note "the above error was encountered while instantiating fn ..." by snapshotting the error count before processing a mono item and comparing it afterwards. The mono item graph is walked in parallel (the par_for_each_in in collect_crate_mono_items), so the global error count can be bumped by an error emitted while collecting a different item on another thread between the two reads. That makes an unrelated item get blamed, which showed up as a spurious note such as

note: the above error was encountered while instantiating `fn std::rt::lang_start::<()>`

appearing nondeterministically in test output under --parallel-frontend-threads.

This adds DiagCtxt::err_count_on_current_thread, backed by a thread-local counter that is bumped next to the shared error count, and uses it for the before/after delta in the collector. It is not affected by errors emitted on other threads. In serial compilation it is equivalent to a delta of err_count.

An alternative that removes the global count entirely, bubbling an ErrorGuaranteed up from each post-monomorphization error source, was explored in #157318. It turns out to be infeasible. Some errors are emitted and then absorbed during collection, so no token ever reaches the collector. In tests/ui/infinite/infinite-instantiation-struct-tail-ice-114484.rs the recursion-limit error is emitted inside CTFE while normalizing a callee FnSig, and the Pointee::Metadata projection recovers the error tail to unit metadata before returning, so eval_constant only ever sees a successful Ok. That recovery cannot be removed: it is what avoids the original #114484 ICE, and propagating the error type instead makes the instantiation collector run away without terminating. The only signal that survives the recovery is the error count, so making that count correct under the parallel frontend by making it per thread is the reliable fix.

The second commit removes the //@ ignore-parallel-frontend post-monomorphization errors directive from the tests listed in the issue and re-blesses the line numbers that shift from dropping the directive line. They were run with --parallel-frontend-threads=16 --iteration-count=40 --force-rerun with no failures.

[rustbot]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @mejrs (or someone else) some time within the next two weeks.

Please see the contribution instructions for more information. Namely, in order to ensure the minimum review times lag, PR authors and assigned reviewers should ensure that the review label (S-waiting-on-review and S-waiting-on-author) stays updated, invoking these commands when appropriate:

• @rustbot author: the review is finished, PR author should check the comments and take action accordingly
• @rustbot review: the author is ready for a review, this PR will be queued again in the reviewer's queue

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 18 candidates

[mejrs]

r? @petrochenkov