remove (more) CAS API from Atomic* types where not natively supported

[japaric]

closes #54276

In PR #51953 I made the Atomic* types available on targets like thumbv6m and
msp430 with the intention of only exposing the load and store API on those
types -- the rest of the API doesn't work on those targets because the are no
native instructions to implement CAS loops.

Unfortunately, it seems I didn't properly cfg away all the CAS API on those
targets, as evidenced in #54276. This PR amends the issue by removing the rest
of the CAS API.

This is technically a breaking change because libraries that were using this
API and were being compiled for e.g. thumbv6m-none-eabi will stop compiling.
However, using those libraries (before this change) in programs (binaries) would
lead to linking errors when compiled for e.g. thumbv6m so this change
effectively shifts a linker error in binaries to a compiler error in libraries.

On a side note: extending the Atomic API is a bit error prone because of these
non-cas targets. Unless the author of the change is aware of these targets and
properly uses #[cfg(atomic = "cas")] they could end up exposing new CAS API on
these targets. I can't think of a test to check that an API is not present on
some target, but we could extend the tidy tool to check that all newly added
atomic API has the #[cfg(atomic = "cas")] attribute unless it's whitelisted in
tidy then the author of the change would have to verify if the API can be used
on non-cas targets.

In any case, I'd like to plug this hole ASAP. We can revisit testing in a
follow-up issue / PR.

r? @alexcrichton
cc @mvirkkunen

[japaric]

The way how I test if an API is natively supported by some target is by writing
a small crate like this:

#![no_std]

use core::sync::atomic::{AtomicUsize, Ordering};

#[no_mangle]
pub unsafe fn foo(x: &AtomicUsize) {
    x.fetch_add(1, Ordering::SeqCst);
}

And the looking at the disassembly

$ cargo objdump --target thumbv6m-none-eabi --lib --release -- -d
Disassembly of section .text.foo:
foo:
       0:       80 b5   push    {r7, lr}
       2:       bf f3 5f 8f     dmb     sy
       6:       01 21   movs    r1, #1
       8:       ff f7 fe ff     bl      #-4
       c:       bf f3 5f 8f     dmb     sy
      10:       80 bd   pop     {r7, pc}

bl #-4 means that this is calling some external function.

$ cargo nm --target thumbv6m-none-eabi --lib --release
foo-75644712abc60497.foo.e45asijs-cgu.0.rcgu.o:
         U __sync_fetch_and_add_4
00000000 T foo

nm reveals the name of the external function.

We could add tests that check that there are no undefined symbols in the output
object file when compiling a small crate like the one shown above, but this
requires the cooperation of tidy to check that a new test is added for each
newly added API.

[alexcrichton]

@bors: r+

[bors]

📌 Commit 8282896 has been approved by alexcrichton

[bors]

☔ The latest upstream changes (presumably #54457) made this pull request unmergeable. Please resolve the merge conflicts.