Introduce a noncopyable Atomic<T> construct

[lorentey]

Now that we have @_rawLayout, it is now possible to start drafting the move-only Atomic<Value> type we always wanted.

This is an early experiment that isn't ready for prime time yet:

0. It requires a compiler with support for the experimental RawLayout feature. (It is currently experimentally available on swift's main branch, which still identifies itself as Swift 5.9.)
1. ~The code is triggering compiler assertions all over the place. These need to be reported and fixed (or worked around).~
2. ~@_rawLayout(like:) currently does not support picking up the layout type from the type argument of the Atomic generic, so this PR unconditionally widens the type's layout to the maximum possible atomic width. (I.e., we use double-wide layout even if we only need to store a single byte's worth of data.)~ Support is now (almost?) working.
3. It might be a good idea to have the atomic representations be themselves noncopyable. However, this would require waiting until such types can conform to protocols, which is likely a bad idea.

Checklist

• [X] I've read the Contribution Guidelines
• [X] My contributions are licensed under the Swift license.
• [X] I've followed the coding style of the rest of the project.
• [X] 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]

CI is going to fail, but just for fun:

@swift-ci test

[lorentey]

This does work well, but I don't expect we'll land it in this form.

We are planning to radically streamline the AtomicValue protocol for the stdlib proposal, and I expect we'll want to land a "packagized" version of that as a brand new module (SynchronizationPackage), completely replacing the current API surface. (Perhaps the new module will ship in a new package, even.)

The nice thing is that most client code that isn't defining its own atomics from scratch will survive without any changes. (Other than changing the import statement and replacing Unsafe/ManagedAtomic with Atomic, of course.)