CG: implicit conversion for required functions

[vasslitvinov]

main issue: #8629     related: #17540

How does CG (constrained generics) design support coercions aka implicit conversions?

Consider three types A, B, C, such that there is an implicit coercion from A to B and from B to C. In my code:

• The interface requires proc foo(x: B).

• Within the CG function, I call foo(arg) where arg has the type A.

• The interface is implemented with proc foo(x: C).

Should this be allowed? This sounds natural.

Cons: we currently do not allow transitive implicit coercion. If an implicit coercion from A to C is not defined, it is invalid to invoke proc foo(x:C) on arg:A. The above scenario would bypass this restriction.

One solution could be to allow only one coercion for any given argument. In the above scenario, either the call within the CG function would have to cast expicitly arg:B or the interface would have to be implemented with proc foo(x:B), not both.

[Added 2021-04-07] The following test requests that promotion be allowed when implementing a required function:

test/constrained-generics/ucol/jturner/min_concept_auto_promote.chpl

[bradcray]

The part about this example that seems surprising to me is that if the interface tells me I have to define proc foo(x: B) that it would be legal for me to define proc foo(x: C) instead (since, if I'm the type author, I could always define the proc foo(x: B) and then do the coercion or cast within the routine). Is there a motivating use case for this? Do constrained generics frameworks in other languages permit it? Can we add it later if we decide we were wrong to be strict about it?