`restriction` lints for undesired method of handling overflow

What it does

wrap_on_overflow would raise a warning if wrapping_add (or similar methods) are invoked.

saturate_on_overflow would raise a warning if saturating_add (or similar methods) are invoked.

Advantage

In my work, I regularly control the behavior on overflow, but I prefer using saturating_*. Unfortunately, for whatever reason, I continue to accidentally type (and thankfully seem to catch) wrapping_*. I'm concerned for the day I write wrapping_ and DON'T catch it. I also have yet to want, in my repository, wrap on overflow and accordingly am fine banning it entirely (without the allow pragma).

I believe a pedantic lint to explicitly declare saturation vs wrap as the preferred way to handle overflow is worthwhile accordingly. This would be approximate to the existing lints establishing preferences on endianess.

Drawbacks

No response

Example

a.wrapping_add(b)

Could be written as:

a.saturating_add(b)

Comparison with existing lints

https://rust-lang.github.io/rust-clippy/master/index.html#arithmetic_side_effects already exists to require a mode be specified, but it doesn't allow declaring a preferred mode.

The premise is comparable to https://rust-lang.github.io/rust-clippy/master/index.html#big_endian_bytes, https://rust-lang.github.io/rust-clippy/master/index.html#host_endian_bytes, https://rust-lang.github.io/rust-clippy/master/index.html#little_endian_bytes which allow declaring a preferred mode to represent bytes.

Additional Context

No response

Start by reading Clippy's existing arithmetic_side_effects and endian-preference lints, using the linked lint documentation as context for how preferences are declared. Determine how wrapping_* and saturating_* methods should be covered and how the preferred mode should be configured. Done means the new pedantic lint consistently warns on the undesired overflow method and documents the supported behavior with examples.