Add support for IntPtr conversion in the call arguments optimizer.

[VSadov]

IntPtr conversion can stay in the bound tree past lowering in a case where a COM method is invoked in an Expression Tree lambda.

Fixes: #11751

[VSadov]

@dotnet/roslyn-compiler - please review

[VSadov]

@MattGertz - for Update3 signoff

The bug results in crashes/watsons when upgrading to VS2015 and rebuilding.
(originally VSO: 222502)

COM + Expression Trees combination is not so uncommon as it might seem. Some mocking frameworks use expression trees extensively and when the tested scenario involves COM methods, it could result in crashing scenarios.

The combination results in IntPtr argument conversions staying in the bound tree past the Call lowering and argument optimizer was not expecting them.
Why COM? - regular invocations inside expression trees do not use named or optional arguments and therefore never need argument optimizing/reshuffling. However COM invocations have additional cases that require them to go through argument temp analysis making it possible to hit the codepath with IntPtr conversions still in the tree. Handling them is trivial, we were just not expecting them.

[MattGertz]

Approved pending CRs.

[cston]

LGTM

[AlekseyTs]

Can we assert that this is happening only when we are producing an expression tree?

[VSadov]

If we are not in an expression tree, IntPtr will cause an assert in codegen anyways. And that one is more reliable since it is not conditional on optimizations being performed.
Also, this method does not have enough context to know we are in an expression tree and I do not want to change that just to get an assert earlier, sometimes.

[AlekseyTs]

LGTM, but do consider adding an assert.

[VSadov]

Will add an assert.
I also think the default case should be assert (not a crash) as well since there is a reasonable default behavior. It is completely safe to assume that unexpected conversions are not reorderable.

[VSadov]

I've decided against an assert specifically for IntPtr conversions. There are many conversion kinds there, which can be seen only under certain conditions, so I do not want to single out just IntPtr one. In particular since this method is static and only needs to sort conversions into "pure" ones and others by kind.

I will replace the exception with an assert though, since there is a correct default behavior.