java: Use a generated keyword matcher to improve performance

[mpkorstanje]

🤔 What's changed?

Improve performance by matching step and title keywords using a generated matcher class.

Before main @ b3413a9

Benchmark                          Mode  Cnt     Score    Error  Units
GherkinParserBenchmarkTest.parse  thrpt    5  1940.849 ± 17.126  ops/s

After

Benchmark                          Mode  Cnt     Score    Error  Units
GherkinParserBenchmarkTest.parse  thrpt    5  2213.691 ± 11.385  ops/s

⚡️ What's your motivation?

In #443 @jkronegg shows that unrolling the loops over the keywords speeds gherkin parsing significantly. I'm not sure about the theoretical underpinnings but the effect is there. This refines that solution by making the unrolling work for an arbitrary number of keywords in each language.

🏷️ What kind of change is this?

• 🏦 Refactoring/debt/DX (improvement to code design, tooling, etc. without changing behaviour)

♻️ Anything particular you want feedback on?

📋 Checklist:

• I agree to respect and uphold the Cucumber Community Code of Conduct
• I've changed the behaviour of the code
  • I have added/updated tests to cover my changes.
• My change requires a change to the documentation.
  • I have updated the documentation accordingly.
• Users should know about my change
  • I have added an entry to the "Unreleased" section of the CHANGELOG, linking to this pull request.

[jkronegg]

Nice job! The generated code looks good and the give confidence on the loop unrolling.
On my realworld project with 740 BDD scenarios, the GherkinMessagesFeatureParser.parse is 25% faster than with the main branch (100 ms -> 75 ms).

[mpkorstanje]

On my realworld project with 740 BDD scenarios, the GherkinMessagesFeatureParser.parse is 25% faster than with the main branch (100 ms -> 75 ms).

That is incredible. If you have more ideas I'd be happy to see them. 👍