Add filtering to rustc_on_unimplemented to avoid misleading suggestion

[estebank]

After #54946, the code let x = [0..10]; for _ in x {} will cause the following output:

error[E0277]: `[std::ops::Range<{integer}>; 1]` is not an iterator
  --> $DIR/array-of-ranges.rs:11:14
   |
LL |     for _ in array_of_range {}
   |              ^^^^^^^^^^^^^^ if you meant to iterate between two values, remove the square brackets
   |
   = help: the trait `std::iter::Iterator` is not implemented for `[std::ops::Range<{integer}>; 1]`
   = note: `[start..end]` is an array of one `Range`; you might have meant to have a `Range` without the brackets: `start..end`
   = note: required by `std::iter::IntoIterator::into_iter`

Add a way to identify this case to rustc_on_unimplemented, in order to avoid giving this misleading/incorrect diagnostic.

[fmease]

Can't the concrete issue regarding [a..b] be fixed by replacing the #[rustc_on_unimplemented] “rule” with a syntactic check in the compiler similar to the logic you implemented in #89251 that suggests a[a.len() - 1] when encountering a[-1]?

[estebank]

@fmease yes, it could be by maybe introducing a new error code or do some special handling of E0277 like we already do for other things, I just have a desire to try to reduce the amount of probing code that we have to implement, and potentially get as "declarative" as possible, but we can indeed do that. The amount of code to get rustc_on_unimplemented to differentiate this and to implement custom handling might be around the same (unless caught earlier).