core: Make most atomic functions generic

[nahla-nee]

CC #130539

The existing PR (#153407) linked in the tracking issue has been dormant for a few months now and can't be merged due to conflicts. Additionally, it only implemented a few functions. This is a big change that implements most atomic functions generically for most types, with notable exceptions being AtomicBool (due to special emulation being difficult to work around), and AtomicPtr (due to not wanting to trample on strict provenance docs).

This is a pretty big change so included below is a list of large changes that were made and the reasoning for them:

1. Adjusted contract for AtomicPrimitive by changing requirement for the associated Storage type.
   Don't permit fewer validity invariants. Existing standard library code does several unsafe casts
   that directly transmute or cast Self to T and vice versa. For example from_mut will accept any
   mutable reference to T and cast it to a mutable reference to Atomic with no invariant checks.
   This condition is doubly asserted by the addition of the stipulation that transmuting between T
   and T::Storage must be valid.

2. Added the associated type OpType to Atomic primitive. Some types (bool) require being cast in
   order to perform operations atomic to an integer or pointer type. Adding this type to the
   contract allows for Atomic to also define generic code for functions such as store/load.

3. Introduced several new traits. These traits match the different "types" of atomics and allow
   specific types to opt into automatic generic implementations of certain classes of atomic
   functions.

4. Introduced new impl_atomic_traits macro to replace existing impl macro. This is mainly to
   support having so many new traits as opposed to just one.

5. Simplified the atomic_int macro and deleted large chunks of it. All the functions implemented
   by this macro are now handled by generics.

P.S. some attributes have been trampled over, specifically the stability attributes for both
const and non-const atomic functions. This is because In some cases a function would be
defined on different atomics with different stability versions, and matching each one to its
type would be a pain. Per a conversation on Zulip that included a library maintainer, it was
suggested that I use the newest version from competing implementation for each function. See
thread titled "How to handle modifying items with stable attribute".

[rustbot]

Thanks for the pull request, and welcome! The Rust Project has assigned @JohnTitor (or someone else) to review your changes, you should hear from them (or someone else) within the next two weeks.

Please see the contribution instructions and our LLM policy for more information.

Why was this reviewer chosen?

The reviewer was selected based on:

• Owners of files modified in this PR: libs
• libs expanded to 12 candidates
• Random selection from JohnTitor, Mark-Simulacrum, clarfonthey

[nahla-nee]

I already got this check from tidy and I had to force push past it. Not only does it "look" wrong it also can't be satisfied as far as I'm seeing. It's essentially asking me to indent that block further, and if I were to do that it simply asks for it to be indented further yet again. I'm not sure if I'm missing something or not.

[nahla-nee]

Seems I got too over zealous. I didn't realize that the lack of unstable impls would cause a problem for the 128 bit atomics. Previous atomic int macro restored (under different name) to implement needed functions for 128bit atomics, and a manual implementation of AtomicPrimitive has been added for them.

[nahla-nee]

Ok, actually fixed now. Added another trait so that implementing AtomicPrimitive doesn't auto implement any traits, and the legacy macro now doesn't cause errors due to not being used on platforms without 128 bit atomics.

[rust-log-analyzer]

The job tidy failed! Check out the build log: (web) (plain enhanced) (plain)

Click to see the possible cause of the failure (guessed by this bot)

[TIMING:end] format::InternalRustfmt {  } -- 14.314
Diff in /checkout/library/core/src/sync/atomic.rs:2914:
         ///
         /// This type has the same
         #[doc = if_8_bit!(
-            $int_type,
-            yes = ["size, alignment, and bit validity"],
-            no = ["size and bit validity"],
-        )]
+                    $int_type,
+                    yes = ["size, alignment, and bit validity"],
+                    no = ["size and bit validity"],
+                )]
         /// as the underlying integer type, [`
         #[doc = $s_int_type]
         /// `].
Diff in /checkout/library/core/src/sync/atomic.rs:2924:
         #[doc = if_8_bit! {
-            $int_type,
-            no = [
-                "However, the alignment of this type is always equal to its ",
-                "size, even on targets where [`", $s_int_type, "`] has a ",
-                "lesser alignment."
-            ],
-        }]
+                    $int_type,
+                    no = [
+                        "However, the alignment of this type is always equal to its ",
+                        "size, even on targets where [`", $s_int_type, "`] has a ",
+                        "lesser alignment."
+                    ],
+                }]
         /// For more about the differences between atomic types and
         /// non-atomic types as well as information about the portability of
         /// this type, please see the [module-level documentation].
Diff in /checkout/library/core/src/sync/atomic.rs:2948:
                 fmt::Debug::fmt(&self.load(Ordering::Relaxed), f)
             }
         }
-    }
+    };
 }