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