Repository: rust
Issue: Tracking issue for `core::ops::*<T>` on `Saturating<T>` / `Wrapping<T>` type
Labels: T-libs-api,C-tracking-issue

<!--
Thank you for creating a tracking issue!

Tracking issues are for tracking a feature from implementation to stabilization.

Make sure to include the relevant RFC for the feature if it has one.

If the new feature is small, it may be fine to skip the RFC process. In that
case, you can use use `issue = "none"` in your initial implementation PR. The
reviewer will ask you to open a tracking issue if they agree your feature can be
added without an RFC.
-->

Relevant RFC "928" (rust-lang/rfcs#928).
 - #87920
 - #32463

<!--
This is a tracking issue for ...
-->

<!--
Include a short description of the feature.
-->

### Public API
The [`Wrapping`](https://doc.rust-lang.org/core/num/struct.Wrapping.html) and [`Saturating`](https://doc.rust-lang.org/core/num/struct.Saturating.html) types enforce that a certain behaviour for all operations on the underlying integer is performed - `.wrapping_*` or `.saturating_*`. When doing the "simplified" operations, `.add` *always* becomes `.wrapping_add` or `.saturating_add`, `.sub` *always* becomes `.wrapping_sub` / `.saturating_sub` and so on.

The fundamental ideas seem to be:
 1. Never perform the an integer operation with the wrong behaviour by forgetting to write `.wrapping_*` or `.saturating_*`
 2. Reduce boiler-plate code / text by being able to omit writing `.wrapping_*` or `.saturating_*`

But number 2 seems to fall short in reality. The traits in `core::ops::` are only implemented for `Wrapping` and `Saturating` where the other type is `Wrapping` or `Saturating` as well (`impl core::ops::*<Wrapping<T>> for Wrapping<T>`¹). So, instead of writing a integer addition like this:
```rust
    let mut value = 17u8;
    // ...
    value += 8;
    value *= 7;
    // ...
    let other: u8 = value / 3;
```
for `Wrapping` and `Saturating` types, it looks likes this:
```rust
    let mut value = Wrapping(17u8);
    // ...
    value += Wrapping(8);
    value *= Wrapping(7);
    // ...
    let other: Wrapping<u8> = value / Wrapping(3);
```

This introduces the need for additional mentions of `Wrapping` /  `Saturating` in every code location where an integer operation is performed - and in my opinion, adds unnecessary noise to the code. In my opinion, having the integer being wrapped in either `Wrapping` or  `Saturating` in the declaration / initialization should be all that is needed.

I propose that - in addition to `impl core::ops::*<Wrapping<T>> for Wrapping<T>`¹ - the integer operations are also implemented using the raw integer type itself (`impl core::ops::*<T> for Wrapping<T>`¹), and therefore the following is being made possible:

```rust
    let mut value = Wrapping(17u8);
    // ...
    value += 8;
    value *= 7;
    // ...
    let other: Wrapping<u8> = value / 3;
```

¹ as well as for `Saturating`
### Steps / History

<!--
For larger features, more steps might be involved.
If the feature is changed later, please add those PRs here as well.
-->

- [x] Decide on wrapping integer (rust-lang/rfcs#928)
- [x] Implement basic `Wrapping` type  #32463
  - [x] Stabilize it
- [x] Implement basic `Saturating` type #87920
  - [ ] Stabilize it (WIP)
- [ ] Add raw integer operations
  - [ ] on `Wrapping` TBD
  - [ ] on `Saturating` #92354
- [ ] Stabilize raw integer operations
  - [ ] on `Wrapping`
  - [ ] on `Saturating`

<!--
Once the feature has gone through a few release cycles and there are no
unresolved questions left, the feature might be ready for stabilization.

If this feature didn't go through the RFC process, a final comment period
(FCP) is always needed before stabilization. This works as follows:

A library API team member can kick off the stabilization process, at which point
the rfcbot will ask all the team members to verify they agree with
stabilization. Once enough members agree and there are no concerns, the final
comment period begins: this issue will be marked as such and will be listed
in the next This Week in Rust newsletter. If no blocking concerns are raised in
that period of 10 days, a stabilzation PR can be opened by anyone.
-->

### Unresolved Questions

<!--
Include any open questions that need to be answered before the feature can be
stabilised. If multiple (unrelated) big questions come up, it can be a good idea
to open a separate issue for each, to make it easier to keep track of the
discussions.

It's useful to link any relevant discussions and conclusions (whether on GitHub,
Zulip, or the internals forum) here.
-->

- RFC vs PR?.
  Following ["The overarching philosophy is: do whatever is easiest"](https://github.com/rust-lang/rfcs/blob/master/libs_changes.md), I created this PR because the underlying types already exist, and it **"only"** proposes additional trait impls. Or does this change need a proper RFC?