[3.0 compat] Don't diagnose @escaping var-arg closures.

[milseman]

• Explanation:  Var-arg closures are already escaping, so we typically want to issue
an error if @escaping is specified. But, we shipped a bug in 3.0 where they needed an explicit @escaping to function properly. Because we don’t expose sub-minor-version control, a library author cannot use escaping var-arg closure parameters in ways that are source-compatible with both 3.0 and 3.0.1. This is especially an issue at least during the period before a GM of 3.0.1.
• Scope of Issue: This affects only escaping closure var-arg parameters. Note that this will slightly worsen the QoI and developer experience when working with 3.0.1 and later in the Swift 3 family of versions. This is because having an extraneous @escaping, that is semantically irrelevant, would give the false impression that it is semantically meaningful. But, this is a corner case situation either way, and thus the confusion is limited in scope.
• Origination: Swift-3, when we added the noescape-by-default rule
• Risk: Very low, as we just skip emitting an error.
• Reviewed By:  Slava
• Testing: Added lit tests
• Directions for QA: none

Resolves SR-2907.

Var-arg closures are already escaping, so we typically want to issue
an error if @escaping is specified. To not do sure will confuse and
give a false impression on the un-annotated semantics and whether it
is needed. But, 3.0 shipped with a bug where we didn't consistently
apply the no-escape-by-default rule here, and thus it was semantically
meaningful (and needed).

In order to preserve source compatibility, albeit at the expense of
developers on versions 3.0.1 and later in the Swift 3 family, we
suppress the error if we see @escaping. Either way, this is a
relatively uncommon usage, so the confusion won't be too wide spread.

[milseman]

@swift-ci please test

[slavapestov]

LGTM, thanks.