Allow suppression of TypeParameterQualifier violations

[Stephan202]

There are valid use cases within Refaster @BeforeTemplate methods.

[Stephan202]

See PicnicSupermarket/error-prone-support#2274 for context. An alternative to this change is #5884, though these PRs are not mutually exclusive.

[cpovirk]

The history here (internal bug 33253939) seems to be that Turbine rejects T.Foo. I can still reproduce that:

third_party/java_src/google_common/current/java/com/google/common/base/Ascii.java:44: error: type parameter used as type qualifier
  private <T extends java.util.Map<?, ?>> Ascii(T.Entry<?, ?> t) {}
                                                ^

I don't know whether Turbine could be made to accept that or not, but apparently we've gotten by OK with a hard rule for many years now.

One possible option would be to allow suppression outside of google3: Even though people on the outside might also be using Turbine (presumably in Bazel), we presumably don't care too much if they get an error from Turbine before one from Error Prone—if they're even using Error Prone, too (though that's likely for Bazel users) and if Error Prone + javac beats Turbine (less likely).

@cushon

[cpovirk]

(more in #5884 (comment))

[cushon]

I don't know whether Turbine could be made to accept that or not, but apparently we've gotten by OK with a hard rule for many years now.

I think it could support them. I looked at it briefly and it'd be possible but would require some additional plumbing in TypeBinder to make it possible to look up type parameters and resolve their bounds when resolving qualified names.

For some turbine history, it started off being more opinionated about not supporting some corners of the language that added implementation complexity and that there was no compelling reason to use (e.g. NonCanonicalStaticImport is another example of one of those corners that inspired and Error Prone check.) Over time I added support for more edges, especially as third party code ran into them.

So if an important open source library starts using this pattern more widely in APIs I think turbine could support it, but I'll probably punt on that until it someone complains :)