Fix support for non-final classes in AtomicReference

[lorentey]

Swift 5.6/7 generates new compiler warnings when non-final classes conform to AtomicReference. The warnings are pointing out a real design issue: Self is covariant in protocols, but we intend atomic operations to always deal with the base class rather than individual subclasses.

Add a new associated type requirement to AtomicValue to represent the actual type that originally conformed to the protocol, and add explicit same-type requirements to clients to ensure they aren’t asked to return a subclass.

Unfortunately, this change is source breaking:

class Base: AtomicReference {}
class Derived: Base {}

let ref = ManagedAtomic<Derived?>(nil)
  // before: builds, but only because a type safety issue isn't caught by the compiler
  // after: 'ManagedAtomic' requires the types 'Derived' and 'Base' be equivalent

Checklist

• I've read the Contribution Guidelines
• My contributions are licensed under the Swift license.
• I've followed the coding style of the rest of the project.
• I've added tests covering all new code paths my change adds to the project (if appropriate).
• I've verified that my change does not break any existing tests.
• I've updated the documentation if necessary.

[lorentey]

@swift-ci test

[lorentey]

@swift-ci test

[lorentey]

The source breakage seems mostly theoretical; it feels like the risk may be low enough to ship this in a minor release, especially since the compiler warning in 5.7 is highlighting a real correctness issue.

(If it turns out this is too optimistic, then we might be able to do something about it, either by continuing to allow broken code in Swift 5.6 (only rejecting it in 5.7), or by tweaking UnsafeAtomic/ManagedAtomic to allow taking subclasses as their generic argument. I suspect the former option would require huge #if compiler(>=5.7) blocks, duplicating large swaths of code. The latter would require the addition of ambiguous overloads marked @_disfavoredOverload. So I'd rather do neither, if at all possible.)

[lorentey]

@swift-ci test

[lorentey]

@swift-ci test

[lorentey]

@swift-ci test macOS platform

[lorentey]

[7/22] Compiling Atomics AtomicOptionalRawRepresentable.swift
/build/swift-atomics/Sources/Atomics/AtomicOptionalRawRepresentable.swift:34:14: error: type of expression is ambiguous without more context
    _storage = Storage(value?.rawValue)
    ~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~

Oh, a fix for that is in #73.

[lorentey]

@swift-ci test