Add named groups for python

[jsa34]

🤔 What's changed?

Expression matching now returns a tuple: the value as before and an optional name if the expression has a name or the regex uses a named capture group.

The format for the Cucumber Expression when specifying name AND type is:

"There are {step_count:int} steps."

Where the part before the colon is the name of the arg, and after is the type we are currently using for Cucumber Expressions.

The return type is change is currently a breaking change, and will have obviously need to put it probably behind some feature flag, and make the default return the old, expected single value again, and the new tuple only if enabled. I have not done this yet as I wanted to check the breadth of test cases if the feature was fully enabled for the PoC before implementing. Also, not sure how best to feature flag!

To resolve #206

⚡️ What's your motivation?

Python (in particular pytest-bdd) uses other args in the step definitions, such as fixtures and reserved args for "datatable" and "docstring", so just mapping step arg values to step args in the expressions is not reliable or user-friendly. It is a blocker currently for adopting Cucumber Expressions into the pytest-bdd framework.

🏷️ What kind of change is this?

• 💥 Breaking change (incompatible changes to the API)

♻️ Anything particular you want feedback on?

Approach, public API changes, format of the named args, whether it's acceptable in general!

📋 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.

---

This text was originally generated from a template, then edited by hand. You can modify the template here.

[jsa34]

This is just my first draft where I made sure that everything "works".

If/once the approach is agreed, I will still need to do tests, documentation, etc., but I thought it more prudent to share the current approach I am suggesting before doing these things!

Feedback most welcome!

I also committed quite a bit of refactoring unrelated to this PR, which I will undo and raise separate PRs for

[luke-hill]

The last time we've done a big change like this I think was the abolition of the Transformer proc. And the introduction of this (cucumber-expressions library), "proper" (But I could be wrong here). So I'd prefer that we go down the route of releasing this all simultaneously.

In terms of feature flags, I'm happy for it to sit behind feature flags - but I'd rather it be simple and purely from a dev POV to avoid us needing to review a leviathan PR. In other words, by all means I'm happy for it to be technically easier to work in whatever way is best, but come our next full release I'd prefer it to be entirely enabled (The major to include this does not need to be the next one - currently v19)

I'm only one of the main contributors though, so it's not entirely my decision. But when cucumber-expressions were released, they were released simultaneously - Admittedly this was a long time ago with many more different people at the helm.

TL;DR - I'm pro this change, and anti it "sitting behind feature flags when released" (But during development go for it).

[davidjgoss]

I don’t have a particular view on the change itself, but do I agree with @luke-hill re flags - I don’t see a lot of value in flags here vs just making it a semver major change and calling attention to it in the release notes. Cucumber implementations that use this library will be pinned to at least a minor range, and other consumers should similarly assume breaking changes in a major.