The constraint solver was eagerly applying the T -> U? conversion
rule, which only succeeds when T is convertible to U. Thus, we would
reject valid code where T has a user-defined conversion to
U?. Instead, introduce a disjunction conversion to try either T -> U?
by converting T to U or via a user-defined conversion.
Most of this is infrastructure for the introduction of constraint
restrictions, which specify that a particular constraint (say, a
conversion constraint) should only try a single direct path:
scalar-to-tuple, value-to-optional, user-defined, etc. Each term in the
disjunction created for the T -> U? case is restricted to a particular
conversion rule, so that checking it does not create another
disjunction.
Keep track of the constraint restrictions we used within a given
solution, so that we can replay those steps during the application
phase. There is a bunch of inactive code here at the moment, which
will become useful as we start creating disjunctions for other
ambiguous conversions.
Swift SVN r9318
Overload bindings constraints bind a given type to a specific overload
choice. This is a step toward moving overload sets into normal
disjunction constraints.
Part of the work here is to eliminate the constraint system's
dependence on OverloadSet, which will be going away in favor of a
disjunction constraint.
Swift SVN r9209
