Fix JDK compatibility issue in LombokHandler and introduce AstHelpersBackports

[msridhar]

Fixes #794. Since the JDK interface change was made for JDK 17, I think even if NullAway was built on and targeted JDK 11, we would still have this problem. I added some hacky unit test coverage for this code so we'd have a way to test for regressions in the future. (The new unit test fails the :nullaway:testJdk8 task without this change.)

We missed this problem earlier since we suppressed a warning from AstHelpersSuggestions. Even though we cannot accept some of the suggestions from that check (since we may not require a recent enough version of Error Prone), the issues it flags can be serious. So, this PR removes all other suppressions of that checker and fixes the warnings. We introduce an AstHelpersBackports class to contain any backported logic from AstHelpers to enable the fixes.

[coveralls]

Pull Request Test Coverage Report for Build #1150

• 0 of 0 changed or added relevant lines in 0 files are covered.
• 87 unchanged lines in 6 files lost coverage.
• Overall coverage increased (+0.3%) to 93.039%

---

Files with Coverage Reduction	New Missed Lines	%
../nullaway/src/main/java/com/uber/nullaway/handlers/AbstractFieldContractHandler.java	5	90.16%
../nullaway/src/main/java/com/uber/nullaway/handlers/ApacheThriftIsSetHandler.java	6	82.76%
../nullaway/src/main/java/com/uber/nullaway/NullabilityUtil.java	7	93.58%
../nullaway/src/main/java/com/uber/nullaway/ErrorBuilder.java	13	87.5%
../nullaway/src/main/java/com/uber/nullaway/dataflow/AccessPathNullnessPropagation.java	20	90.24%
../nullaway/src/main/java/com/uber/nullaway/NullAway.java	36	95.81%

Totals
Change from base Build #1146:	0.3%
Covered Lines:	5627
Relevant Lines:	6048

---

💛 - Coveralls

[lazaroclapp]

One minor question which applies to the code both before and after, but otherwise, this LGTM!

[lazaroclapp]

Not sure I get, from these docs, what's the difference or problem with calling Symbol.getEnclosedElements() directly...

[msridhar]

See here. Sometime after JDK 11, some subclasses of Symbol were changed to override getEnclosedElements() with a covariant return type (returning com.sun.tools.javac.util.List instead of java.util.List). So, e.g., if your code directly invokes getEnclosedElements() on a variable of type ClassSymbol, and you compile on JDK 17, the bytecode signature at the call site will have a return type of com.sun.tools.javac.util.List. Then when you try to run this code on JDK 11, it fails, since a method with that exact return type cannot be found. This issue occurs even if you set your source and target bytecode level to 11 (or 8). Using this wrapper method works around the problem, since the declared target of the call will always be Symbol.getEnclosedElements().