Separate the dependency between Gherkin and Messages

[mpkorstanje]

🤔 What's the problem you're trying to solve?

Currently the Gherkin parser parsers directly into message objects. This means that

• When messages updates, Gherkin gets an update.
• When messages updates, projects that dependency on messages transitively through Gherkin gets an update.
• When a project wants to upgrade Gherkin they have to upgrade Messages
• When a project wants to upgrade Messages they have to upgrade Gherkin

And because messages gets major releases, Gherkin also gets frequent major releases. This has a lot of bad effects all around.

• Messages can not be released and upgraded in a Cucumber implementation independently from Gherkin (each release of messages has to be propagated to Gherkin first). This results in busy work for maintainers that is frequently not done.
• Upgrading either Gherkin or Messages results in quite a bit of mandatory work for down stream maintainers (e.g. Update go.mod messages#107 (comment)).
• And because messages are also used as the interface between different Cucumber implementations and various plugins these now also get Mandatory upgrades (e.g. allure-framework/allure-java@a79c669).

This makes the ecosystem around Cucumber either unreliable or stagnant depending on what release strategy a maintainer favors.

✨ What's your proposed solution?

1. The Gherkin parser produces an AST that is similair to, but not the equivalent of Message
2. Cucumber implementations map the AST to a Message
3. Extend the CCK with the acceptance test examples from Gherkin
4. Validate the mapping in a Cucumber implemetnation is correct using the CCK.

⛏ Have you considered any alternatives or workarounds?

I could be possible to make changes to Gherkin and Messages less frequently, but given that this is an Opensource project that mostly runs on people spare time such obstacles would likely discourage contribution in the first place.