Lint on (nearly) all `{integer}`/`{float}` fallback

Note: this is currently at the phase of a lang vibe check, not an approved proposal. I personally currently think I like it, but if you're interested in working on it beware that the answer might end up being "no, we don't want a lint for that".

The integer fallback to i32 and float fallback to f64 is very important for beginner friendliness. We absolutely want a simple thing like

println!("{}", 123.456);

or

for x in 0..10 {
    println!("{}", x);
}

to compile, because we don't want to add extra friction to the "my first rust program" examples.

That said, it's not obvious that fallback is what you want in "real" code, and you'd much prefer it be unified to something the vast majority of the time. Like for i in 0..10 { a[i] = 0; } ends up constrained by the indexing, and similar. And any time something is derived from an argument or returned that unifies the integer/float type as well.

See for example #139087 where there's no type to unify with, just a trait bound, and not having the type annotation causes evolution problems.

We'll probably find some examples where it turns out that we need to allow it -- maybe x << 4 for example will need to continue to allow fallback, for example, since it's a heterogeneous RHS -- but what would people think about this general direction?

(It feels like at very least it should exist for the "I'm a popular crate who really wants to make sure I'm not broken by updates to things" group we keep talking about.)

No files, tests, or compiler entry points are named. Begin by reviewing the fallback examples and the discussion in #139087, then determine whether a general lint is wanted and which cases must remain allowed; the issue has no settled acceptance criteria.