[6.2] Sema: Make @concurrent not imply async on closures

[AnthonyLatsis]

• Explanation:
  The present approach is not prudent because @concurrent synchronous functions, a natural extension, are a likely-to-happen future direction, whereas the current inference rule is entirely grounded on @concurrent being exclusive to async functions.

  If we were to ship this rule, we would have to keep the promise for backwards compatibility when implementing the aforementioned future direction, replacing one inconsistency with another, and possibly introducing new bug-prone expression checking code.

  func foo(_: () -> Void) {}
  func foo(_: () async -> Void) {}
  
  // In a future without this change and  `@concurrent` synchronous
  // functions accepted, the first call resolves to the first overload,
  // and the second call resolves to the second, despite `@concurrent` no
  // longer implying `async`.
  foo { }
  foo { @concurrent in }

  This change also drops the fix-it for removing @concurrent when used on a synchronous closure. With the inference rule gone, and the diagnosis delayed until after solution application, this error raises a fairly balanced choice between removing the attribute and being explicit about the effect, where a unilateral suggestion is quite possibly more harmful than useful.

• Scope: Type-checking for explicitly @concurrent closures.

• Issues: —

• Original PRs: Sema: Make @concurrent not imply async on closures #83094.

• Risk: Overall low, medium for potentially existing adopters because closures that were previously inferred as async due to the attribute alone will now error.

• Testing: Regression tests added, source compatibility suite run.

• Reviewers: @xedin.

[AnthonyLatsis]

@swift-ci please test

[AnthonyLatsis]

@swift-ci please test Windows