Allow some way of marking lints as TODO

[shepmaster]

I'd like there to be some way to gradually introduce clippy to a code base without having to fix all the existing problems but also minimizing or preventing new violations.

---

My preferred workflow when introducing new lints to an existing code base is:

1. Install the tool.
2. Have the tool generate a "TODO" file that marks all existing lint violations as ignored.

• Ideally this file is split into two dimensions: file and lint type.

At this point, I commit and push this progress. This prevents any files from getting worse. Then, the team cycles on the following steps:

1. Pick a single lint that is being ignored.
2. Fix all of or a subset of the files for that one lint, and push it.

What's interesting to note is that this entire process usually repeats when a new version of the linting tool is released, as this often introduces new lints that we have been unknowingly violating.

This is strongly influenced by RuboCop.

/cc #1295, killercup/rustfix#36

[shepmaster]

As @oli-obk points out:

#[allow(...)] is for when you want to actually not address the lint; you want to address the lint, but not now

And also ponders:

I wonder if we can make it so the TODO file knows which lints it has reported where, so if you add a new case of the lint in the same file, it'll still figure it out
line numbers aren't sufficient, but it might work with some structural information
although that might break on a refactoring

I think we can generate a "path" like Foo::bar if the lint occurs in impl Foo { fn bar() { /*here*/ } }
and then complain if any new entries show up. Entries disappearing would just remove them from the TODO file

[camsteffen]

I think this should be a crate, not a Clippy feature: imagine - cargo allowlints adds #![allow(warned_lint)] to your lib.rs. Or something like that.