fix: resolve MediatR/Mediator request types from referenced assemblies

[yatmund]

Summary

Basically I just wanted to be able to use ALT + H / Go To handler directly from Mediator.Send() or the command within it and it wasn't quite working

Description

Go-to-handler did nothing on modern MediatR (12+) and Mediator setups. IsRequestTypeSupported looked up a PSI module named exactly "MediatR" or "Mediator" and resolved IBaseRequest/INotification from it, and Library.InitializeTypeElementsIfNeeded scoped the handler-interface lookup to that same single assembly. Since MediatR 10 those interfaces ship in MediatR.Contracts.dll, and Mediator's ship in Mediator.Abstractions.dll, so the types never resolved. IsRequest then returned false and FindHandlers returned nothing.

Resolve both the marker interfaces and the handler interfaces from the project module plus its references instead of a pinned assembly, and drop the now-unused moduleName plumbing.

Also:

• Add MediatorCallSite so "Go to Handler" works with the caret anywhere inside a mediator.Send(...) / Publish(...) call. It resolves the first argument's type instead of requiring navigation to the request first.
• Raise the InheritorsConsumer cap so large solutions with many handler implementations are not truncated before the match is found.

[kzryzstof]

Thanks for this. I want to make sure I understand the failure mode before merging, since I couldn't reproduce it. A few questions:

On the module-name lookup: I checked what's actually inside these packages:

MediatR/12.5.0            → lib/net6.0/MediatR.dll        (assembly name "MediatR")
MediatR.Contracts/2.0.1   → lib/netstandard2.0/MediatR.Contracts.dll
Mediator.Abstractions/3.0.2 → lib/net8.0/Mediator.dll     (assembly name "Mediator")

Both MediatR and Mediator still exist as physical assembly names, and Library.InitializeTypeElementsIfNeeded already resolves its symbol scope with withReferences: true (predates this PR), which should reach into MediatR.Contracts.dll as a reference of MediatR.dll. Given that, do you know specifically why the module-name lookup was failing in your repro: was it a solution shape where the project doesn't reference the main MediatR/Mediator package directly (e.g. only MediatR.Contracts), or something else? I'd like to capture that shape in a test rather than guess at it.

On reproducing it: #122 (merged into main since you opened this) added SDK-level lookup tests that restore real MediatR/12.5.0, 13.1.0, 14.2.0, and Mediator.Abstractions/3.0.2 packages and assert FindHandlers resolves correctly. They pass against the pre-this-PR code:
https://github.com/Octelys/mediator-plugin/actions/runs/34135934798/job/101786789518

Does that match the setup you were hitting the bug in, or was yours meaningfully different (multi-project solution, a specific package combination, etc.)? If you can point me to a minimal repro, I can turn it into a regression test.

On MediatorCallSite: separately from the module-resolution question — was the actual symptom you hit "ALT+H does nothing with the caret on Send(...)"? If so, that part doesn't need the module-resolution change to explain it; the old code just returned early on selectedTreeNode is not IIdentifier. Want to confirm before I ask for a test here too.

On MaxInheritors: what solution size prompted raising this to 20000? Trying to figure out if a fixed cap is the right shape, or if this should scale with something instead.

Once I know which of these is doing the actual work, happy to help get a regression test in and get this merged.

[yatmund]

Thanks for looking into this!

So the MaxInheritors number was just pulled out of thin air really, the reason why things weren't quite working for me was that 50 was to low for the solutions I'm working on, I've reduced it 300. One of my solutions goes to 167 IRequestHandler implementations, wouldn't be surprised if some of our older ones goes beyond 300...

I think your latest round of fixes, have helped with the module name look up stuff as well so I've dropped that.

I also see you're looking at the Go To Handler stuff for .Send()? (yay!)

[kzryzstof]

I also see you're looking at the Go To Handler stuff for .Send()? (yay!)

Well, I saw your PR, liked the idea but realized I was not comfortable not having any automated tests. So I added some yesterday and thought why not try add more tests related the feature you suggested :)