swift234

Start enforcing strict keyword argument usage and ordering under -strict-keyword-arguments.

Implement a completely new path for matching up an argument tuple to a
parameter tuple, which handles the specific rules we want for
calls. The rules are:

  - The keyword arguments at the call site must match those of the
    declaration; one cannot omit a keyword argument if the declaration
    requires it, nor can one provide a keyword argument if the
    declaration doesn't have one.
  - Arguments must be passed in order, except that arguments for
    parameters with defaults can be re-ordered among themselves (we
    can't test all of this because neither constraint application nor
    the AST can express these).

QoI is extremely important in this area, and this change improves the
situation considerably. We now provide good diagnostics for several
important cases, with Fix-Its to clean up the code:

  - Missing keyword arguments:

    t.swift:8:13: error: missing argument labels 'x:y:' in call
    allkeywords1(1, 2)
                ^
                 x: y:

  - Extraneous keyword arguments:

    t.swift:17:12: error: extraneous argument labels 'x:y:' in call
    nokeywords1(x: 1, y: 1)
               ^~~~   ~~~

  - General confusion over keyword arguments (some missing, some
    wrong, etc.):

    t.swift:26:14: error: incorrect argument labels in call (have
        'x:_:z:', expected '_:y:z:')
    somekeywords1(x: 1, 2, z: 3)
                 ^~~~
                        y:

There are still a few areas where the keyword-argument-related
diagnostics are awful, which correspond to FIXMEs in this
implementation:

  - Duplicated arguments: f(x: 1, x: 2)
  - Extraneous arguments: f(x: 1, y: 2, z: 3) where f takes only 2
    parameters
  - Missing arguments
  - Arguments that are out-of-order
  - Proper matching of arguments to parameters for diagnostics that
    complain about type errors.

And, of course, since this has only been lightly tested, there are
undoubtedly other issues lurking.

This new checking is somewhat disjoint from what constraint
application can handle, so we can type-check some things that will
then fail catastrophically at constraint application time. That work
is still to come, as is the AST work to actually represent everything
we intend to allow.

This is part of <rdar://problem/14462349>.

Swift SVN r17341