Incorrect overload resolution ends in type error.

[stephan-herrmann]

• record when Poly*Method is part of a set of overloads
  • in that case don't propagate premature bounds inner -> outer

Fixes #2941

[stephan-herrmann]

Initially during inference, resolving from(stream) could not select an overload due to insufficient type information. At this point three things are created: two PolyParameterizedMethodBinding, one for each of the candidates, and one ProblemMethodBinding(Ambiguous) holding one of the candidates as its closestMatch. This opportunistic selection is where declaration order influenced the outcome. Somehow that closest match surfaced in our implementation of 18.5.2.2. (specifically: addConstraintsToC_OneExpr()), where the type information of the inner from(stream) influenced the outer inference. When the wrong overload is used, this led to inference not finding the desired solution.

To fix this we'll now refuse to add further constraints based on type information from unresolved overload disambiguation. To detect the situation, at the point where we create the ProblemMethodBinding(Ambiguous) we tag the closestMatch PolyParameterizedMethodBinding as having overloads. That flag then prevents spilling premature information into outer inference.