Fix misleading return type diagnostic for input type mismatch

[BartSimpson001]

Summary

Fixes #163443.

Avoid emitting the misleading "the return type of this call is ..." help when
an argument type mismatch does not actually affect type inference.

Previously, the diagnostic was emitted whenever the mismatched argument's type
was a generic parameter that also appeared in the function's output type. This
is misleading when the parameter is already constrained by another input, e.g.
in MaybeUninit<u32>::write(&mut self, val: T) -> &mut T, where T is fixed
by self, so the return type does not depend on the argument at all.

This PR adds a condition so the help is only emitted when no other input
parameter of the signature mentions the same type. In that case the argument
really is the only thing that could influence the return type.

While here, the signature index (sig_idx) is now computed once (accounting for
the self receiver on methods) and reused for the lookup.

Testing

• Added a UI regression test for Confusing diagnostics about return type for input type mismatch #163443
  (tests/ui/mismatched_types/return-type-note-constrained-generic-issue-163443.rs and its .stderr).
• Verified with:
  ./x test tests/ui/mismatched_types/return-type-note-constrained-generic-issue-163443.rs

LLM disclosure

I used an LLM during the development of this change to help analyze the issue
and understand the relevant rustc code and diagnostic behavior. The
implementation and changes were written by me. I ran the test myself and
generated the .stderr output with --bless, then reviewed it manually to
confirm it matches the desired output from the issue.

[rustbot]

Thanks for the pull request, and welcome! The Rust Project has assigned @oli-obk (or someone else) to review your changes, you should hear from them (or someone else) within the next two weeks.

Please see the contribution instructions and our LLM policy for more information.

Why was this reviewer chosen?

The reviewer was selected based on:

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

[oli-obk]

Please avoid using a testing section in the future. It's implicit in the diff. Only include it if you did sth out of the normal usage. Also the section header for summary is redundant, the main PR comment should start with it

[oli-obk]

@rustbot reroll

to find an LLM reviewer (not because it was generated, but because I don't have the energy to figure out if new contributors are biting off things too large for them because the LLM assistance made it somewhat possible to produce sth that passes tests)

[BartSimpson001]

@oli-obk Just a small clarification: I’ve previously contributed to rust-ice and the Rust standard library, so I’m not completely new to Rust contributions.