Added initial support for explicit tuple conversions

[VSadov]

By itself supporting explicit tuple conversions is fairly trivial. We just apply explicit conversions element-wise. Similar to implicit tuple conversions.

The complicated part is interaction between implicit and explicit conversions. In particular C# permits cases where T converts to U via distinct implicit and explicit conversions. In such and cases a cast in code can act as disambiguator.

 T t = new T();
 U u = t;          // implicit cast T->U is used
 U u = (U)t;       // explicit cast T->U is preferred

In this change we are trying to generalize this rule to tuple conversions. (yet to be confirmed with LDM).

 (T, T) tt = (new T(), new T());
 (U, U) uu = tt;                // implicit cast T->U is used
 (U, U) uu = ((U, U))tt         // explicit cast T->U is preferred
 (U, U)? uu = ((U, U)?)tt       // explicit cast T->U is preferred 

UNDONE in this change:

• In the last case lowering does not yet match the desired behavior (implicit conversion wins). The work to enable that is tracked by Propagate preferences between explicit and implicit conversions into nullable conversions #12064
• Explicit conversions from literals are not supported pending LDM decision.
  tracked by Implement ExplicitTupleLiteralConversion #11804
• Now that Conversion can contain nested conversions, just for the IsValid purpose, it would seem to be useful to just store it on the bound conversion nodes and reduce cases where we need to classify casts at lowering.
  This could be a big but fairly mechanical change, not affecting any functionality (hopefully) so better be done separately.
  As a part of this change it could make sense to make Conversion type more compact, possibly even make it a reference type.
  Tracked by Consider storing Conversion on bound conversion nodes and use at lowering. #12067
• ConversionBase could use some refactoring.
  Some similar helper are separated between two files, some helpers for conversions from expressions and types and those that handle casts in code are not named uniformly. It is possible there is some duplication.
  Makes sense to bundle with Consider storing Conversion on bound conversion nodes and use at lowering. #12067
• Coverage of conversion classification through APIs could be improved. For now there is some coverage coming from preexisting tests, however there would be a need to test some corner case scenarios.
  Especially once Propagate preferences between explicit and implicit conversions into nullable conversions #12064 and Implement ExplicitTupleLiteralConversion #11804 are resolved and it is confirmed that the whole deal with distributing "Cast In Code" stays.

[VSadov]

@dotnet/roslyn-compiler - please take a look

[VSadov]

WIll remove that. It is unnecessary.

[agocke]

LGTM aside from concern about dynamic

[VSadov]

@dotnet-bot test this please

[VSadov]

Could not make this ImmutableArray because of a false-circularity bug in CLR loader.
The shape of this type is likely to change as a part of #12067

[gafter]

I think the system ones are supposed to go at the top. ¯\_(ツ)_/¯

[gafter]

[VSadov]

@dotnet-bot test perf_correctness_prtest please
@dotnet-bot test windows_eta_open_prtest please

[AlekseyTs]

Should we return an implicit conversion in this case?

[AlekseyTs]

And in some cases below?

---

In reply to: 67725469 [](ancestors = 67725469)

[VSadov]

It should report ExplicitNullable. Both implicit and explicit conversions exist in this case and you get one or another depending on what you are classifying.
The caller used to report ExplicitNullable in all preexisting cases here even before this change.