Tag scoped step definitions

### 🤔 What's the problem you're trying to solve?
Bind step definition to tags (e.g. 'When I press "Save"' multiple definitions for different tags).

Many steps are worded identical, but refer to different operations of the system. Consider a web interface, where multiple ways to display the interface exist, multiple pages, or dialogs, all with a "Save" button. They might need different implementation on how the save action is triggered in the test glue code, but right now you would always need to specify something clumsy like `When I press "Save" (on page X)`, which is not only odd to read but raises questions.

In the glue code you would have multiple implementations, all with slightly different wordings, making it a huge mess to come up with variants on how you write the same action.

Another very common occurrence is the "Then I expect no error to be shown" steps. This is usually easily scopeable with a tag in a feature file talking about whatever way errors are displayed or returned in that particular part of the system. However we find ourselves always having to write the error validations absurdly verbose.

### ✨ What's your proposed solution?

SpecFLOW (for .NET) has solved this quite elegantly: A step definition can be bound to one or multiple tags. It is then only relevant for Scenarios or features with that specific tag. This way the wording can be sharper and shorter, and the glue logic is more readable.

### ⛏ Have you considered any alternatives or workarounds?

Right now we have to pre or postfix steps that are worded the same but have to trigger two different actions in the test implementation, and it does actually work against the idea of Cucumber: to make the specification independent from the implementation