Fix build error with targets that do not support atomic CAS operations

[taiki-e]

Some no-std targets (e.g., ARMv6-M) do not support atomic CAS operations and cannot use Arc, etc.

$ cargo build --target thumbv6m-none-eabi --no-default-features --features alloc -p valuable
error[E0433]: failed to resolve: could not find `sync` in `alloc`
   --> valuable/src/enumerable.rs:217:52
    |
217 | impl<E: ?Sized + Enumerable> Enumerable for alloc::sync::Arc<E> {
    |                                                    ^^^^ could not find `sync` in `alloc`

This patch detects those targets using the TARGET environment variables provided by cargo for the build script, and a list of targets that do not support atomic CAS operations.

This way is the same as the way we recently adopted in futures, and was originally inspired by the way heapless and defmt do, but this doesn't maintain the target list manually. (It's not really fully automated, but it's very easy to update.)

refs: rust-lang/rust#51953, rust-lang/futures-rs#2400
related: tokio-rs/bytes#461

[taiki-e]

In futures, there was a question about compatibility with custom targets, so we exposed a similar cfg as an unstable public API.

We can also treat it as a private API until there is an actual request, but this cfg is unstable and we can change/remove it at any time, so I think it is also ok as-is. (Whether this cfg is considered private or public depends on how the comments describe about it, so either way, it is a very simple change.)

Btw, one reason for the instability is that this cfg can eventually be replaced by cfg(accessible). So I believe this cfg will never be a stable API.

[taiki-e]

We'll need to implement similar detection logic for atomic integers later, so it's probably better to make this private for now. I'll update PR...

UPDATE: done in f7f1b95

[carllerche]

Thanks. This strategy is great.