Enhance type inference errors involving the ? operator

[wabain]

This patch adds a special-cased note on type inference errors when the error span points to a ? return. It also makes the primary label for such errors "cannot infer type of ? error" in cases where before we would have only said "cannot infer type".

One beneficiary of this change is async blocks, where we can't explicitly annotate the return type and so may not generate any other help (#77880); this lets us at least print the error type we're converting from and anything we know about the type we can't fully infer. More generally, it signposts that an implicit conversion is happening that may have impeded type inference the user was expecting. We already do something similar for mismatched type errors.

The check for a relevant ? operator is built into the existing HIR traversal which looks for places that could be annotated to resolve the error. That means we could identify ? uses anywhere in the function that output the type we can't infer, but this patch just sticks to adding the note if the primary span given for the error has the operator; if there are other expressions where the type occurs and one of them is selected for the error instead, it's more likely that the ? operator's implicit conversion isn't the sole cause of the inference failure and that adding an additional diagnostic would just be noise. I added a ui test for one such case.

The data about the ? conversion is passed around in a UseDiagnostic enum that in theory could be used to add more of this kind of note in the future. It was also just easier to pass around than something with a more specific name. There are some follow-up refactoring commits for the code that generates the error label, which was already pretty involved and made a bit more complicated by this change.

[rust-highfive]

r? @davidtwco

(rust-highfive has picked a reviewer for you, use r? to override)

[wabain]

There are various cases where we shrink the span used in the error message after the HIR traversal, so this check makes sure that the note still makes sense with the chosen span.

[davidtwco]

LGTM, left a few minor suggestions.

[wabain]

Merge conflicts and suggested changes are resolved

[davidtwco]

@bors r+

Thanks!

[bors]

📌 Commit d46c3e3 has been approved by davidtwco

[bors]

⌛ Testing commit d46c3e3 with merge 497c9a2...

[bors]

☀️ Test successful - checks-actions
Approved by: davidtwco
Pushing 497c9a2 to master...