[Constraint system] Introduce a one-way constraint for a switch subject.

The normal type checking of switch statements checks the switch subject
first, without context, then evaluates the cases. Introduce a one-way
constraint into the type checking of switch statements within function
builders to provide this same behavior. The difference can be observed
in code such as:

    enum E {
      case a
      case b(Int, String?)
    }

    enum E2 {
      case b(Int, String?)
    }

    func getSomeEnumOverloaded(_: Double) -> E { return .a }
    func getSomeEnumOverloaded(_: Int) -> E2 { return .b(0, nil) }

    func f() {
      switch getSomeEnumOverloaded(17) {
      case .a:  // error: no member named "a" in E2
        print("a")
      default:
        print("default")
      }
    }

When the subject expression `getSomeEnumOverloaded(17)` is resolved
without consider cases, it will select the second
`getSomeEnumOverloaded(_:)`, because the literal 17 prefers to be
an `Int`. The type checking of the first case would then fail because E2
does not contain a member named "a".

Prior to this change, the same expression within a function
builder would succeed in type checking, because the lack of case named
"a" within "E2" would make the second getSomeEnumOverloaded() unusable.

Making this code work by considering the cases along with the subject
expression is not unreasonable, and may be the right long term
direction for the language. However, it's a feature that should be
discussed separately, and the semantics should agree between function
builders and normal statements.

Big thanks to John McCall for noting the missing one-way constraint!

Author: DougGregor

lib/Sema/BuilderTransform.cpp

@@ -627,6 +627,9 @@ class BuilderClosureVisitor
     // type for use in matching the various patterns.
     Expr *subjectExpr = switchStmt->getSubjectExpr();
     if (cs) {
+      // Form a one-way constraint to prevent backward propagation.
+      subjectExpr = new (ctx) OneWayExpr(subjectExpr);
+
       // FIXME: Add contextual type purpose for switch subjects?
       SolutionApplicationTarget target(subjectExpr, dc, CTP_Unused, Type(),
                                        /*isDiscarded=*/false);

test/Constraints/function_builder_diags.swift

@@ -377,3 +377,25 @@ func testSwitch(e: E) {
   }
 }
 
+// Ensure that we don't back-propagate constraints to the subject
+// expression. This is a potential avenue for future exploration, but
+// is currently not supported by switch statements outside of function
+// builders. It's better to be consistent for now.
+enum E2 {
+  case b(Int, String?) // expected-note{{'b' declared here}}
+}
+
+func getSomeEnumOverloaded(_: Double) -> E { return .a }
+func getSomeEnumOverloaded(_: Int) -> E2 { return .b(0, nil) }
+
+func testOverloadedSwitch() {
+  tuplify(true) { c in
+    // FIXME: Bad source location.
+    switch getSomeEnumOverloaded(17) { // expected-error{{type 'E2' has no member 'a'; did you mean 'b'?}}
+    case .a:
+      "a"
+    default:
+      "default"
+    }
+  }
+}