Fix expand-availability syntax not to interfere with doc comment parsing

[lorentey]

swift-system is shipping both as an ABI stable module in Apple SDKs, and as a source-stable package. Both variants are built from the same codebase, but for the SDK builds, we need to annotate each declaration with the first OS versions that shipped them.

We use the script Utilities/expand-availability.py to add or remove availability annotations from our sources, depending on context.

(The Swift compiler supports actual availability macros these days, however, unfortunately they require the use of command-line options that are considered "unsafe" by SwiftPM -- so we cannot use availability macros in packages.)

The script uses specially formatted comments to find the appropriate places for availability expansions. Our previous syntax convention was this:

/// Fiddle with the thing.
/*System 0.0.2*/
public func foo()

/// Fiddle with the thing.
/*System 0.0.2, @available(macOS 12.0, iOS 15.0, watchOS 8.0, tvOS 15.0, *)*/
public func foo()

/// Fiddle with the thing.
/*System 0.0.2*/@available(macOS 12.0, iOS 15.0, watchOS 8.0, tvOS 15.0, *)
public func foo()

Unfortunately, regular comments in between a declaration and its preceding doc comments interfere with documentation tools.

This PR changes things to the style below instead:

/// Fiddle with the thing.
@available(/*System 0.0.2*/macOS 10, *)
public func foo()

/// Fiddle with the thing.
@available(/*SwiftSystem 0.0.2: macOS 12.0, iOS 15.0, watchOS 8.0, tvOS 15.0*/macOS 10, *)
public func foo()

/// Fiddle with the thing.
@available(/*SwiftSystem 0.0.2*/macOS 12.0, iOS 15.0, watchOS 8.0, tvOS 15.0, *)
public func foo()

Unfortunately, @available(*) isn’t valid syntax, so we have to add a dummy “macOS 10” version spec. It should have no actual effect.

[lorentey]

@swift-ci test

[amartini51]

This spelling looks like it shouldn't interfere with DocC parsing the declaration and comments.

[lorentey]

I updated these commits to change macOS 10 to iOS 8 -- the latter is the shortest platform version string that matches the minimum possible deployment target for Swift code. (Using a real version number avoids bogus availability showing up in, say, auto-generated API synopses.)

@available(iOS 8, *) is functionally equivalent to not having an @available attribute at all.

An alternative would be to put in all platforms, but I feel @available(macOS 10.9, iOS 8, watchOS 2, tvOS 9, *) would be way too verbose / confusing to consider.

[lorentey]

@swift-ci test

[lorentey]

@swift-ci test