Fix #7082: Refine overloading resolution with default arguments

[odersky]

We previously had a fallback to pick methods without default arguments
over methods with default arguments as a final tie breaker. (Rolling the
distinction into the specificity test was tried previously, but without
success). The fallback only worked if there was a single alternative
without default arguments. This is now generalized to the case where
there are several such alternatives.

Also, we now avoid mentioning inapplicable alternatives in overloading
ambiguity error messages.

[bishabosha]

If I add another method def foo[V](x: Int = 0, y: Int = 0, z: Int = 0, q: Int = 0): Nothing = ???, in addition to the error about overloaded alternatives, we also get polluting merge errors and double definitions:

-- Error: local/OverloadsNeg.scala:11:2 ----------------------------------------
11 |  foo(1)
   |  ^
   |  cannot merge
   |    method foo$default$2 in object Overloads of type [V] => Int  and
   |    method foo$default$2 in object Overloads of type [V] => Int
   |  they are both defined in object Overloads but have matching signatures
   |    [V] => Int and
   |    [V] => Int
   |  as members of value <skolem>
   |         
-- Error: local/OverloadsNeg.scala:5:6 -----------------------------------------
5 |  def foo[V](x: Int = 0, y: Int = 0, z: Int = 0): Nothing = ???
  |      ^
  |      two or more overloaded variants of method foo have default arguments
-- [E120] Duplicate Symbol Error: local/OverloadsNeg.scala:5:10 ----------------
5 |  def foo[V](x: Int = 0, y: Int = 0, z: Int = 0): Nothing = ???
  |          ^
  |          Double definition:
  |          def foo$default$1: [V] => Int in object Overloads at line 3 and
  |          def foo$default$1: [V] => Int in object Overloads at line 5
  |          have the same type after erasure.
three errors found

[odersky]

@bishabosha Merge errors are probably unavoidable here. I think it's OK to leave it as is.