Detect and fix situations when (force) unwrap is used on
a non-optional type, this helps to diagnose invalid unwraps
precisely and provide fix-its.
Resolves: [SR-8977](https://bugs.swift.org/browse/SR-8977)
Resolves: rdar://problem/45218255
Suggest to add `()` (form a call) to correctly forward argument function
originated from `@autoclosure` parameter to function parameter itself
marked as `@autoclosure`.
Let's keep track of type mismatch between type deduced
for the body of the closure vs. what is requested
contextually, it makes it much easier to diagnose
problems like:
```swift
func foo(_: () -> Int) {}
foo { "hello" }
```
Because we can pin-point problematic area of the source
when the rest of the system is consistent.
Resolves: rdar://problem/40537960
When constructing requirement failures make sure that requirement
kind provided by the caller matches information about requirement
stored in the locator.
Merge logic from `diagnoseAssignmentFailure` and `diagnoseSubElementFailure`
into new `AssignmentFailure`, together with their support functions, which
decouples `CSDiagnostics` from `CSDiag` and scrubs latter from some functionality.
The flag is used to indicate that caller is interested in
diagnostic to be a note instead of an error, it's useful
when trying to diagnose ambiguities.
This is going to make adding same-type and superclass requirement
failures might easier, because they only have to supply custom
diagnostic messages and substituted types.
Change logic to traverse the chain of declaration contexts
starting for "affected" declaration's parent and check if the
requirement is satisfied by one of them, if so return it as
requirement's declaration context.
Extract this logic into a method on `RequirementFailure` to make
it accessible for other types of requirement failure diagnostics.
