[_AtomicShims] On Darwin, ensure we link against libswiftCore using assembly shenanigans

[lorentey]

Like #95 and #96, the intention here is to avoid a linker failure when the build system decides to build this module as a standalone library.

Hopefully this will all go away soon, when swift_retain_n/swift_release_n will become primitives exposed by the stdlib.

Resolves #55

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.
• [ ] I've added tests covering all new code paths my change adds to the project (if appropriate).
• [X] I've verified that my change does not break any existing tests.
• [ ] I've updated the documentation if necessary.

[lorentey]

@swift-ci test

[lorentey]

Local testing confirms that this resolves the issue that's plaguing #55 (and rdar://108390931).

[lorentey]

Local testing confirms that this resolves the issue that's plaguing https://github.com/apple/swift-atomics/issues/55 (and rdar://108390931).

Not so fast! It looks like the method I'm using to override the swift-atomics release tag with a local checkout also resolves it, by itself. Grr.

[lorentey]

@swift-ci test

[rvsrvs]

@lorentey does Swift 5.9 expose swift_retain_n and swift_release_n? Thinking this would fix all my problems with playgrounds!