This can happen if an application is compiled for .NET 4.6.2 and references
System.ValueTuple.dll; but ILSpy loads the latest mscorlib (e.g. .NET 4.7)
which also contains struct System.ValueTuple.
While support for multi-module assemblies isn't fully working yet; it is clear at this point that we want
to treat each module in a multi-module assembly separately for the purposes of the type system.
This was the last place where the public API of the resolved TS was referencing the unresolved TS.
We could now implement the resolved TS directly using SRM, and remove the whole unresolved TS layer.
* Use tuple literals instead of calling 'new ValueTuple<..>' constructor
* Where available, use element names for field access
* Make CallBuilder aware of tuple-name/dynamic type erasure, to avoid introducing casts when the types differ only in the tuple element names.
* Make CallBuilder provide a ResolveResult with the correct C# return type for the resulting expression.
Previously we were using the type-erased return type from the IL.
* Fix a bug that caused us to introduce returning casts when accessing an indexer.
Daniel Grunwald