swift234

Revamp how value & type member constraint failures are diagnosed, eliminating the
"unavoidable failure" path, along with Failure::DoesNotHaveNonMutatingMember and
just doing some basic disambiguation in CSDiags.

This provides some benefits:
 - Allows us to plug in much more specific diagnostics for the existing "only has 
   mutating members" diagnostic, including producing notes for why the base expr
   isn't mutable (see e.g. test/Sema/immutability.swift diffs).
 - Corrects issues where we'd drop full decl name info for selector references.
 - Wordsmiths diagnostics to not complain about "values of type Foo.Type" instead 
   complaining about "type Foo"
 - Where before we would diagnose all failures with "has no member named", we now
   distinguish between when there is no member, and when you can't use it.  When you
   can't use it, you get a vauge "cannot use it" diagnostic, but...
 - This provides an infrastructure for diagnosing other kinds of problems (e.g. 
   trying to use a private member or a static member from an instance).
 - Improves a number of cases where failed type member constraints would produce uglier
   diagnostics than a different constraint failure would.
 - Resolves a number of rdars, e.g. (and probably others):
   <rdar://problem/20294245> QoI: Error message mentions value rather than key for subscript



Swift SVN r30715