Update library/generated callsites of Marshal.QueryInterface for .NET 9

[Sergio0694]

Proposal: update library/generated callsites of Marshal.QueryInterface for .NET 9

Summary

Tracking issue for dotnet/runtime#94470.
Here's my thoughts from dotnet/runtime#94470 (comment):

• For multi-targeted sources, they can just use ref, and suppress the warning on .NET 9 and above (CS9191). Even without suppressing it, it'll just be a warning though, and not an actual build error. Of course, suppressing it is recommended, but just saying, it should never fail to built outright in this scenario.
• For source-generated files, they can either also just use ref and suppress the warning again, or detect the signature of the method, pass it down to the incremental model and use that to decide what modifier to emit. Either is doable, of course the latter is a tiny bit more involved.

The general idea is that with .NET 9 changing the signature to in, we need to make sure no scenario is source breaking.

[AaronRobinsonMSFT]

we need to make sure no scenario is source breaking.

We need a bit more care on this front. Source that is written and owned by a team can easily tolerate new warnings as they can be suppressed in a myriad of forms. However, source that is generated has a higher bar because the levers of control are more limited and can cause friction with company policy. The CsWinRT is free to make the final call here, but I would endevour to avoid warnings in all cases and narrowly suppress so there is no friction on adoption.

[dongle-the-gadget]

I think dealing with that right now should be quite easy, as all files that are using it aren’t generated, but rather predefined.