Surface IOperation info to allow analyzers to detect shadow copies for non-readonly methods over in params

[Sergio0694]

Follow up from the conversation with @jaredpar and @CyrusNajmabadi in #roslyn in the C# Discord server.

Background and Motivation

A big issue with in parameters today is that they can introduce shadow copies when:

1. Invoking non-readonly members on an in struct parameter.
2. Invoking any member on an in T generic parameter, regardless of whether the runtime type/member is readonly.

There currently is no way to spot them, you just have to know, and even then, it's easy to accidentally introduce copies without noticing, as there is zero compiler help here. Introducing copies can at best still defeat the whole point of using in, which is to avoid copies and improve performance, and at worst just flat out break the code, in case it relied on being invoked on the original value.

Proposal

There should be enough info on IOperation to allow analyzer authors to spot all hidden copies done by Roslyn. Not familiar with the API surface there so I don't have an exact API proposal here, but I know Jared will be able to fill the blanks here 😄

Risks

None that I can see.

[CyrusNajmabadi]

@333fred for thoughts. Do the bound nodes know/expose if they introduced a defensive copy?

[sharwell]

I've discussed this in the past with @mavasani. I believe it will need a new top-level analyzer callback for value copies. In addition to potentially having a copy on any IOperation node, there are situations where a copy can occur without any IOperation representation available.