New strategy for polymorphic overloads with apply members

Instead of doing overload selection directly on the result of the
PolyType which contains unbounded paramrefs, we now first call
`wildApprox` to get rid of the paramrefs. The resulting behavior is
different from what Scala 2 does, but it makes polymorphic overloads
with apply members behave more like polymorphic overloads with a
parameter list, e.g given:

    def a(x: Any): Any
    def a[T <: Int]: T => T
    a(1)

    def b(x: Any): Any
    def b[T <: Int](x: T): T
    b(1)

in both cases the second overload will be selected.

Author: smarter

compiler/src/dotty/tools/dotc/typer/Applications.scala

@@ -1521,7 +1521,7 @@ trait Applications extends Compatibility { self: Typer with Dynamic =>
       if (tryApply(alt)) {
         val qual = alt.widen match {
           case pt: PolyType =>
-            pt.resultType
+            wildApprox(pt.resultType)
           case _ =>
             alt
         }

tests/neg/poly-overloads.scala

@@ -8,17 +8,16 @@ class A {
   def foo2[T]: T => String = ???
 
   foo2(1): String // ok
-  foo2("") // error, because T isn't instantiated before overloading resolution is done
+  foo2("") // ok, unlike Scala 2
 
   def foo3(x: Any): Any = x
   def foo3[T <: Int]: T => T = x => x
 
   val a = foo3(1) // ok
-  val b: Int = a // error because the non-apply alternative was chosen, like in Scala 2
+  val b: Int = a // ok, unlike Scala 2 which prefers the first overload
 
   def foo4(x: Any): Any = x
   def foo4[T >: Int]: T => T = x => x
 
-  val c = foo4(1) // ok
-  val d: Int = c // ok
+  val c = foo4(1) // error, unlike Scala 2 this is ambiguous
 }