Update styleguide to include a rule around annotations

[Wiemer]

Examples in the styleguide that involve annotations are displayed as

@State var someVariable: String

@obj private func someFunction() {
    /// ...
}

but this rule is not called out explicitly. In order to make it clearer that this is the expectation and to provide something to point to when not followed proposing to add a rule around annotations to the guide.

[Tyler Thompson]

Note: I frequently call them "Annotations". However, Apple calls them attributes

I think it's a tad confusing because "Annotation" is what they are called in other languages, like C#, Java, and Kotlin.

[Tyler Thompson]

Suggestion:

PREFER attributes on the same line as what they are attributing.

// RIGHT
@State var stateVar: Bool = true
@discardableResult func thing() -> Bool { true }
@MainActor class MyClass { 
    // ...
}

// WRONG
@objc
func thingExposedToObjectiveC() {
    // ...
}

Exceptions:
When there are so many attributes that this becomes unreasonable:

// WRONG
@ViewBuilder @discardableResult @MainActor @inlinable func betYouDoNotEvenKnowWhatThisFunctionDoesAnymore() {
    // ...
}

Why?

Because we naturally read lines of code as a consistent line, introducing whitespace makes it that much harder to understand the full context of the line you're trying to understand. This is the same reasoning we put behind preferring a return on the same line as the final parameter in a function declaration.

NOTE: This doesn't come at the cost of sanity. If you have an exceptionally large number of attributions then a: It might indicate you've gotten overzealous and b: it actually obscures your meaning, rather than add to it.

[Tyler Thompson]

Another notable exception, @available attributes by convention are almost always put on their own line. Partially because of their length, but also because of the kind of scope they apply to a declaration.

[Richard Gist]

Closed by #63