Tidy up const_ops, rename to const_arith_ops

[clarfonthey]

Tracking issue: #143802

This is split into three commits for ease of reviewability:

1. Updates the forward_ref_* macros to accept multiple attributes (in anticipation of needing rust_const_unstable attributes) and also require attributes in these macros. Since the default attribute only helps for the initial implementations, it means it's easy to get wrong for future implementations, as shown for the saturating implementations which were incorrect before.
2. Renames const_ops feature to const_arith_ops and adds constness and trivial implementations to the remaining traits in core::ops::arith.
3. Constifies the rest of the reasonable implementations.

A few random other notes on the implementation specifically:

• Unfortunately, without Tracking Issue for macro_named_capture_groups #142999 implemented, we can't make the constness in the forward_ref_* macros work nicely without copy-pasting the macro body. Instead of doing that, I decided to go for a cursed extra const argument, which is then used for the actual const keyword. I explicitly mention named macro capture groups as a way of doing this better in the comments.
• I unindented the attributes that were passed to the forward_ref_* macro calls because in some places rustfmt wanted them to be unindented, and in others it was allowed because they were themselves inside of macro bodies. I chose the consistent indenting even though I (personally) think it looks worse.

---

As far as the actual changes go, this renames the const_ops feature to const_arith_ops (anticipating, e.g., const_bit_ops) and constifies the following additional traits:

• Neg
• AddAssign
• SubAssign
• MulAssign
• DivAssign
• RemAssign

In terms of constified implementations of these traits, it adds the reference-forwarded versions of all the arithmetic operators, which are defined by the macros in library/core/src/internal_macros.rs. I'm not going to fully enumerate these because we'd be here all day, but sufficed to say, it effectively allows adding an & to one or both sides of an operator for primitives.

Additionally, I constified the implementations for Wrapping, Saturating, and Duration as well, since all of them forward to already-const-stable methods. Specifically for Duration, the ref-forwarding is not present.

[rustbot]

r? @ibraheemdev

rustbot has assigned @ibraheemdev.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[rustbot]

Some changes occurred in src/tools/clippy

cc @rust-lang/clippy

[hkBst]

What is this for?

[samueltardieu]

This hides a real issue: to know whether it can replace "a = a OP b" by "a OP= b" (where OP is, for example, "+"), Clippy looks for the const-stability of the sole associated item of the trait corresponding to "OP=". Here, AddAssign is now identified as const-stable, and Clippy attempts to replace a = a + b; by a += b; in a const context, when a is of a generic type implementing AddAssign.

[samueltardieu]

This might be what triggers the Clippy issue. It looks like the AddAssign::add_assign() associated function is seen as being const-stable.