Add availabilityAttributes property to Symbol

[MattKiazyk]

This is to partially support #105 and the @available attributes.

AvailabilityAttribute

I've added a property to Symbol called availabilityAttributes to support any attributes that are on the Symbol. SwiftSemantics already has support for this, so just drawing out the specific available attribute into it's own property

 public var availabilityAttributes: [AvailabilityAttribute] {

enum AvailabilityAttributeType

I decided to code all the specific attributes inside the AvailabilityAttributeType enum. This allows the HTML or MarkDown, to check for specific attribute and change the UI accordingly.

The init?(from argument: Attribute.Argument) { is a little awkward I will admit. I was trying to handle the various scenarios of @available where sometimes you can have a version, sometimes not. It turned into something a little ugly, but looking for feedback, and perhaps you had another direction for it.

There is no UI change for HTML or Markdown, but the first step in supporting making that change.

[mattt]

Thanks for taking this on, @MattKiazyk!

I agree with your assessment in #105 that swift-doc should incorporate availability information into its generated output. And adding styling cues, like striking out deprecated symbols would be a quick win. Eventually, it'd be nice to reconcile individual symbol availability with the package's declared deployment targets.

I keep going back and forth about whether this functionality belongs in SwiftDoc or SwiftSemantics. But for now, I think the right approach would be have an Availability type that initializes from a SwiftSemantics Attribute value, as well as eventually from a Swift package manifest, compiled artifact, or index entry. That way, we can support both the short- and long-term goals stated above.

The init?(from argument: Attribute.Argument) { is a little awkward I will admit. I was trying to handle the various scenarios of @available where sometimes you can have a version, sometimes not. It turned into something a little ugly, but looking for feedback, and perhaps you had another direction for it.

Some of that awkwardness is a consequence of @available being a shared spelling for two separate concepts: language availability and platform availability, with the latter having both a longhand and shorthand form. I wrote more about this in this NSHipster article.

What I'd like to see from this PR is this:

• An Available type with better alignment with how the Swift compiler / Clang understands API availability
• Support for arbitrary platform names, both to accommodate existing ones like _PackageDescription and Linux, as well as future ones like wasm and Windows.
• Comprehensive tests for initializing from availability attributes. Given the wide variety of possible inputs, we should do our best to provide extensive coverage. For reference, take a look at the Swift compiler's tests for availability versions

[MattKiazyk]

@mattt made some more changes to the Availability type. This should better allow arbitrary platform names.

I tried to best split out the platform/version for future use where we could filter based on that.

Also added more tests for a variety of different @available options.

[MattKiazyk]

@mattt just wondering if there's anything I can do to move this forward?