feat: editor tokens for the names of Feature, Rule, Scenario keywords

[ant0x64]

Fixes #248

This feature introduces new token classifications for the names of Feature, Rule and Scenario blocks in Cucumber feature files:

• Feature: keyword is now tokenized as namespace:cucumber
• Rule: keyword is now tokenized as class:cucumber
• Scenario: keyword is now tokenized as function:cucumber

🏷️ What kind of change is this?

• ⚡ New feature (non-breaking change which adds new behaviour)

[luke-hill]

@michaelboyles can you review this?

[michaelboyles]

Seems like a hack really. 'Scenario' is not semantically a function and 'Rule' is not semantically a class. You could make the argument that Feature is a namespace of sorts, I guess.

You're basically assigning any otherwise-unused token type, just so it's unique from the others. The root issue that is monaco doesn't let you style distinct keywords with different styles.

I think there are 3 problems with this PR

1. it alters existing theming behaviour for other users that they don't necessarily want

2. the relationship between a keyword and its semantic token type is now less clear, because some of them are just arbitrary. In practical terms, it's harder to style correctly, because how do I know that "Scenario" = "function" without looking at this code?

3. there may more relevant uses for these token types in the future, and abusing them now may restrict us from using them in the future

[ant0x64]

@luke-hill, my mistake, fixed tests.

[ant0x64]

@michaelboyles,

I agree that mapping Feature, Rule, and Scenario to namespace, class, and function isn't semantically perfect. However, from the available token types, these seemed like the most appropriate fit.

I also considered leaving Feature as keyword and assigning Rule as a namespace instead, but I felt this was ultimately a subjective choice that could be adjusted based on consensus.

"In practical terms, it's harder to style correctly, because how do I know that 'Scenario' = 'function' without looking at this code?"

As someone new to this package, I’d appreciate guidance on how this mapping is typically surfaced. Personally, I’ve been using VSCode’s built-in Editor Token Inspection Tool to identify token types for styling. Is there a more maintainable or standard approach to documenting or discovering these token mappings?

I understand the concern about future token use conflicts and theming side effects. I’m very open to alternative suggestions or a better strategy if there’s a preferred path forward

[mpkorstanje]

I'm afraid that at present we collectively lack the expertise to make such a decision - one way or another.