RFR: [DRAFT] Support Java literals in @Param annotation

[Vsevolod Tolstopyatov]

This is a follow-up to https://mail.openjdk.java.net/pipermail/jmh-dev/2020-October/003039.html

I've prototyped it and found few corners which I'd like to highlight and discuss.

The initial purpose of the change is to be able to use underscores for the sake of better readability in both code and text reports:

`@Param("1_000", "10_000", "100_000")` 

and


Benchmark        (listSize)   Mode  Cnt      Score   Error  Units
ShowOff.consume       1_000  thrpt       42294.795          ops/s
ShowOff.consume      10_000  thrpt        4057.322          ops/s
ShowOff.consume     100_000  thrpt        2866.069          ops/s



While doing so, I've decided that it would be nice to support the strict subset of actual Java literals (at least to have a reference to point at) which has a lot of pitfalls:

* Now we have (?) to support octal, binary and hexadecimal literals
* The actual grammar is quite wild, so literals like `0_12___3_4` are also supported
* `l` and `L` at the end of `long` literals are not supported (it seems a bit weird to do so)
* `NumericLiteralsParser` leaks to public API, so the generated benchmarks can invoke it (not sure what's the API policy here, but it's worth pointing it out)
* Underscores in floating points literals are not supported, mostly because then I have to match hexadecimal literals with underscores as well. No particular reason apart from "it's extra work without clear benefits". I can implement it if it's required for the PR though.

Most importantly, support of such literals will break existing benchmarks that prefixed their numeric parameters with zero -- now they are interpreted as octal literals (and either rejected, e.g. `09` or converted to decimal, breaking the original authors intent). Previously, `X.parseX` functions (e.g. `Integer.parseInt`) were used and they are okay with leading zeroes.

Breaking change seems to be the blocker here, and I'd like to hear your opinion of the acceptable approach aligned with JMH API

Potential alternatives:

* Do nothing, don't support underscores
* Support only decimal literals
* Support any subset of literals (e.g. decimal and hexadecimal only)
* Just trim all the underscores and parse it as before via `Integer.parseInt` and so on

-------------

Commit messages:
 - Support Java literals in @Param annotation

Changes: https://git.openjdk.java.net/jmh/pull/50/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jmh&pr=50&range=00
  Stats: 411 lines in 6 files changed: 378 ins; 21 del; 12 mod
  Patch: https://git.openjdk.java.net/jmh/pull/50.diff
  Fetch: git fetch https://git.openjdk.java.net/jmh pull/50/head:pull/50

PR: https://git.openjdk.java.net/jmh/pull/50