[Accelerate] Declare availability where missing, remove where redundant

[lorentey]

Accelerate.vImage, .vDSP and .vForce are introduced in macOS 10.15 / iOS 13, but they are currently declared without availability.

• Add the missing @available attributes to them and their extensions.
• Remove newly redundant @available attributes from the ~500 entry points defined in vImage/vDSP/vForce extensions. (Their availability is now inherited from the top-level extension.)
• Adjust remaining declarations that have 9999 availability to reflect the actual OS versions that introduce them.

[lorentey]

@swift-ci test

[swift-ci]

Build failed
Swift Test OS X Platform
Git Sha - 2cc38fc

[lorentey]

@stephentyrone In its current state this will conflict with your 9999 PR :(

Feel free to merge that first if you like -- I already have a version of this based on that.

[jrose-apple]

@xymus, did you get in your change for availability on extensions to propagate to members? If not, this isn't safe to take yet either.

[lorentey]

@jrose-apple Is that a new issue? I think this has "always" worked:

@available(macOS 42, *) // nonsense "future" version
extension Array {
  func foo() {}
}

[1, 2, 3].foo() // error: 'foo()' is only available in macOS 42 or newer

[lorentey]

(I can revert the last commit if we need to keep the attributes on the individual members, but then we'll also need to review the codebase to make sure we have them everywhere. I don't think even Accelerate declares @available on every new entry point in every new extension.)

[xymus]

This should be safe, the availability attribute worked as expected to declare an introduction version on extensions. My fix (#24997) was for the use of unavailable and obsoleted on extensions, which are still broken. #24997 been reverted but the blocker should itself be fixed soon.

[lorentey]

Merging to fix the ABI issue of missing @available decls. I'll submit a cherry pick to 5.1 in a jiffy.