add lint: could_be_assoc_type_bounds

[y21]

Closes #12925.

The issue explains the two patterns it looks for, but to quickly summarize:

fn f1<T: Iterator>() where <I as Iterator>::Item: Copy {}
// and
fn f2<T: Iterator<Item = U>, U: Copy>() {}

can both be

fn f1<T: Iterator<Item: Copy>>() {}

This ended up far more involved than I originally expected and it's a bit annoying just how much code is required to have a proper machine applicable suggestion that can handle all the ways these bounds can be written.

TBH I'm not sure if it's worth all the complexity, but oh well (especially considering that something like <T as Trait>::Assoc: Copy, <T as Trait>::Assoc: Clone, which requires buffering the lint, is probably rather rare). The current suggestion still relies a bit on rustfmt to clean up, like a trailing comma because I didn't want to make it even more complicated than it already is, but I think it should be fine.

There's the question if we want to lint impl Trait types (<T: Iterator<Item = impl Copy>> -> <T: Iterator<Item: Copy>>). My initial implementation naturally linted them beacuse they're desugared to the pattern we already detect, but calling it a complexity issue is a stretch IMO as it barely saves a few characters so for now I just ignored them, and the lint description/messages would need some special casing.

changelog: new lint: could_be_assoc_type_bounds

[rustbot]

r? @Alexendoo

rustbot has assigned @Alexendoo.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[y21]

One case where the lint relies on rustfmt to cleanup. Naively removing both the leading or trailing comma would create overlapping spans when trying to remove two bounds next to each other (removing the middle comma in T: Copy, U: Copy twice), so that's why it only tries to remove trailing commas