Use cfg(target_has_atomic) on no-std targets to support platforms without atomic CAS (no dep)

[taiki-e]

This does not replace #467 ("Add feature to support platforms without atomic CAS"), but is sufficient to fix #461 in use cases that do not need Bytes/BytesMut. (i.e., What some of the people who say we need #479 ("Make alloc optional") actually need.)

The following documentation added by this PR should explain exactly the status of the API after this PR is merged and its relationship to #467:

On no_std environment without atomic CAS, such as thumbv6m, Bytes and BytesMut are currently not provided.
See #467 for the proposal about support these types on such a environment.

---

This implements the first one listed in #573 (comment).

• Now that cfg_target_has_atomic is stable, cfg_attr(target_os = "none", cfg(target_has_atomic = "ptr")) can be used to remove the need of the build script in Add feature to support platforms without atomic CAS #467. However, it increases MSRV for target_os = "none" targets.

The concern with this approach was MSRV of the cfg(target_os = "none") targets, but I have been using this approach with futures-rs for over a year and have not received any complaints about this. Below is an explanation to this MSRV concern from futures-rs PR (rust-lang/futures-rs#2811) that implemented it.

This increases the MSRV of the cfg(target_os = "none") targets to Rust 1.60, but since they are all tier2/tier3 targets in rustc and those use cases usually require at least 1.59 for inline-asm, it would be acceptable for them to have a slightly higher MSRV than the other targets.

(Btw, futures-rs also implements the same approach as #467, not only this.)

[Darksonn]

Sorry for the delays on the other PR. I'm okay with adding this, though I have one question: If we go through with #479, would that make this PR redundant? It would let you compile out the Bytes type, which I believe gets rid of all atomic ops.