Include import prefixes on hover types when available

[FMorschel]

Inspired by #33695, #56935 and #56350, I'm requesting that types on hovers, when applicable, should display the import prefix/alias to help differentiate.

---

When multiple aliases are available for one declaration:

• If we can infer from the expression being hovered, use that
• Use first

---

WDYT @srawlins, @bwilkerson?

[srawlins]

I like it.

[bwilkerson]

When do we think it would be possible to infer an import prefix? Obviously in an expression where there's a prefix, but when else?

If it's too inconsistent / unpredictable it might be confusing. I'd also like to have some understanding of how hard it would be to implement / maintain.

[FMorschel]

When do we think it would be possible to infer an import prefix? Obviously in an expression where there's a prefix, but when else?
[...] I'd also like to have some understanding of how hard it would be to implement / maintain.

Since we already have the information on the library that defines the type, my guess (and I've looked arround once or twice at that code) is that the code handling this uses the element/fragment so looking at namespaces would be easy enough, I believe, for both implementing and maintaining.

If it's too inconsistent / unpredictable it might be confusing.

I would not expect that to happen, I don't have any numbers but my guess is that rarely users have more than one library that exposes the same things, and even more so, with different aliases. And in those cases, the expression would probably have a hint as to which import prefix should be used if we wanted to try and tackle that, but it might not be necessary.