Non-saturating arithmetic on saturating types

What it does

Ensures that Saturating types aren't accidentally misused.

I've had a tuple with a Saturating<u8> field, and I've written num.0 += 1 thinking I'm accessing a field of my tuple, but actually it was the number itself, and I accidentally accessed the inner value of the Saturating wrapper, and ended up having overflowing arithmetic instead.

Advantage

Ensures the wrapper type isn't accidentally bypassed. The whole point of the wrapper is to ensure it's used.

Drawbacks

Someone might want to perform direct arithmetic on the inner type when knowing it won't overflow, but in that case maybe an explicit allow(lint) wouldn't be too bad to communicate the intention. Or they could just use the wrapper type when the arithmetic is obviously in bounds and the optimizer can remove range checks.

Example

    let mut n = Saturating(0u8);
    n.0 += 100;

Could be written as:

    let mut n = Saturating(0u8);
    n += 100;

Start with the issue's Saturating examples and clarify the intended lint behavior for direct field arithmetic versus wrapper arithmetic. Then locate the relevant Clippy lint entry point and its tests; done means the misuse is detected while the explicitly wrapper-based form remains valid.