Suggestion of `explicit_infinite_iterator` for `OneSidedRange`

What it does

For a given iterator using a one sided range (i..) where i: T it suggests changing it with (i..T::Max).cycle() in the interest of explicitness.

Advantage

• Remove divergence between debug and release builds(right now, the following code fails with overflow in debug, but goes into infinite loop in release mode.

fn main() {
    for i in 0_u8.. {
        println!("{}", i);
    }
}

• It prevents unintentional infinite loops, aiding infinite_iter and maybe_infinite_iter

Drawbacks

It suggests a change in behavior for the debug build.

Example

fn main() {
    for i in 0_u8.. {
        println!("{}", i);
    }
}

Could be written as:

fn main() {
    for i in (0_u8..u8::MAX).cycle() {
        println!("{}", i);
    }
}

The issue names no files, tests, or entry points. Start by tracing how Clippy represents and tests iterator-related lints, then resolve the proposed behavior and debug-versus-release tradeoff before defining the lint's scope and acceptance tests.