Add a lint for closure trait impls

[thomcc]

This sucked to write, but should be good enough. It will catch a lot of external crates incorrectly though, without the refinement.

[thomcc]

This is not the best example because trait Foo where Self: Blah is shorthand for trait Foo: Blah, and is actually quite easy to check for in HIR.

However, there are other examples where other traits could be indirectly implemented via bounds on the impl, and this is the simplest such example.

[workingjubilee]

Either closure_trait_impl.rs or config-lints.md should explain the specific problem more exactly: We want to ban projecting a return type that is incorrectly considered 'static despite in actuality being lifetime-bound.

[workingjubilee]

It would be nice to have an example of a crate that this too-conservative lint would nail that we want to allow but I consider that purely extra. This will be good with the doc change I mentioned.

[workingjubilee]

With this diff I mentioned wanting, or some variation of this:

[thomcc]

It would be nice to have an example of a crate that this too-conservative lint would nail that we want to allow but I consider that purely extra

I don't think this is what you mean, but for clarity: if you are asking for this as a uitest, I do not want to start adding known-bug uitests yet, I think it could cause confusion, and I would eventually like to add some rules that we should be careful about reviewing changes to the stderr uitest files, since they currently should be very rare.

If you just want an example, well, it's still tricky but only because the pattern doesnt lend itself to github code search. These impls are semi-common, because the function traits are #[fundamental] -- the blanket impl doesn't forbid other things. As mentioned it's hard to search for, but https://github.com/rust-lang/rust/blob/fd68a6ded951bd7b852ab8107007f7145e3ad6ec/library/core/src/str/pattern.rs#L602-L610 is an example from the stdlib (and I'm sure there are more).

Such impls are fine, because they don't give access to the return type as an associated type. This is true if they show up in dependencies, this isn't a case where we are weakened if a dep is added where this falsely triggers (although if a dep did provide access to the return type, it would be a problem).

[workingjubilee]

definitely not as a uitest, just wondering if we can find examples to use to help motivate our own discussions/research later. I expect we'll encounter them face-first tho'.