[CS] Avoid introducing Void closure result binding for hole

If we have a hole binding for the result of a closure, avoid
introducing Void as an additional binding since that'll just cause
local solution ambiguities. This doesn't affect regular type-checking
since we end up treating such ambiguities as "identical", so we just
pick one. But for completion, we don't do such filtering so need to
make sure we end up with the hole solution to avoid treating Void as
the contextual type for cases such as:

```
_ = {
    x.#^CC^#
}
```

Currently we avoid this by not handling holes in `repairFailures`
for closure body locators, but I'm changing that in the next commit.

Author: hamishknight

lib/Sema/CSBindings.cpp

@@ -2681,8 +2681,11 @@ bool TypeVarBindingProducer::computeNext() {
       // let's have it try `Void` as well because there is an
       // implicit conversion `() -> T` to `() -> Void` and this
       // helps to avoid creating a thunk to support it.
+      // Avoid doing this is we already have a hole binding since
+      // introducing Void will just cause local solution ambiguities.
       if (getLocator()->isLastElement<LocatorPathElt::ClosureResult>() &&
-          binding.Kind == AllowedBindingKind::Supertypes) {
+          binding.Kind == AllowedBindingKind::Supertypes &&
+          !binding.BindingType->isPlaceholder()) {
         auto voidType = CS.getASTContext().TheEmptyTupleType;
         addNewBinding(binding.withSameSource(voidType, BindingKind::Exact));
       }