Add -XepMaxWarnings:N to fail a compilation that reports more than N warnings

[diegourban]

Today the only way to fail a build on Error Prone warnings is -Werror. But that stops reporting after the first class with a warning (#4546)

This PR adds -XepMaxWarnings:N. Error Prone counts the findings it reports at WARNING severity. When the compilation finishes, it reports an error if the count is above N:

error: Error Prone reported 3 warnings, which exceeds the maximum of 2 set by -XepMaxWarnings

• -XepMaxWarnings:0 is the "fail if anything is found, but report everything" requested in fail if there any problems are detected, but report all problems found #4546.
• N > 0 also lets a codebase with existing warnings stop the count from growing and lower it over time (seen in Collecting ideas for a new set of configuration options #648).

[cpovirk]

I've been slightly more active in this repo of late, but I'm not really at the point at which I'd consider myself qualified to sign off on a change like this.

That said:

For preventing backsliding

Our own approach has generally been to increase the severity of individual checks from WARN to ERROR (or to promote all warnings to errors), perhaps demoting some ERROR checks to WARN: https://errorprone.info/docs/flags#severity. That doesn't work quite as well if you have, say, 37 warnings of one type and you want to avoid adding more. But for that case, we tend to spray @SuppressWarnings around with // TODO: ... comments, enable the error, and then clean those up as time goes by.

For displaying multiple errors

I forget what happened with #4546 (comment), but I'd hope that Error Prone could be made to do that by default, rather than requiring opt-in changes to its configuration, including ones that make all warnings (beyond a threshold, which might itself need to be adjusted over time) into errors.

[diegourban]

@cpovirk thanks for taking a look, and for the context on how this is usually handled internally.

To clarify the goal: it is mostly after a gate, so that new warnings fail the build instead of piling up unnoticed.

On thresholds above zero: the per-check ERROR plus @SuppressWarnings/TODO approach makes sense when warnings are concentrated in a few checks. Where I have found it harder is legacy code with hundreds of warnings spread across many checks, where the suppressions end up as noise in the code. A count leaves the code alone and gives one number to lower gradually over time.