Feature/unescape backslashes config

[qualityisaculture]

🤔 What's changed?

Added a new configuration option cucumber.unescapeBackslashes that allows users to unescape backslashes in Cucumber Expression patterns when reading JavaScript or TypeScript step definition files.

Implementation details:

• Added cucumber.unescapeBackslashes boolean configuration option (default: false)
• Modified VscodeFiles.readFile() to apply backslash unescaping to file content when the config is enabled
• The config is read dynamically on each file read, so changes take effect immediately without requiring an extension restart
• Added comprehensive test coverage for the new functionality
• Updated documentation in README.md and package.json

Files changed:

• package.json - Added new config option definition
• README.md - Added documentation section with explanation and use case
• scripts/update-settings-docs.sh - Updated to sync new config documentation
• src/VscodeFiles.ts - Implemented backslash unescaping logic
• src/test/suite/VscodeFiles.test.ts - Added test suite (4 new tests)
• CHANGELOG.md - Added entry under [Unreleased]

⚡️ What's your motivation?

This change fixes an issue where the library sometimes interprets \\/ (two backslashes) instead of \/ (one backslash) when reading step definitions from JavaScript/TypeScript source code. Specifically when using the badeball preprocessor with Cypress.

The Problem:
In Cucumber Expressions, you need to escape a forward slash with a backslash (\/) for alternative text behavior. In JavaScript source code, backslashes themselves must be escaped, so developers write "\\/" to achieve \/ at runtime. However, when the extension reads these files, the library sometimes interprets \\/ as two backslashes instead of one, causing incorrect pattern matching.

The Solution:
This new config option converts escaped backslashes (\\) back to regular backslashes (\) in file content, ensuring correct interpretation of Cucumber Expression patterns.

🏷️ What kind of change is this?

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

This is a non-breaking change because:

• The default value is false, maintaining existing behavior
• Users must explicitly opt-in to enable the feature
• No existing functionality is modified when the config is disabled

♻️ Anything particular you want feedback on?

• Implementation approach: I chose to read the config dynamically on each readFile() call rather than caching it in the constructor. This ensures config changes take effect immediately, but I'm open to feedback if there's a better approach or performance concerns.
• Test coverage: I've added tests for the main scenarios, but I think they may be overly complicated. They are integration tests with VSCode, and perhaps just unit tests would be sufficient?
• Documentation: I've documented the feature in README.md with a link to the alternative text behavior documentation. Please let me know if the explanation is clear or if additional context would be helpful.
• Release Version: I have not incremented the release version. I presume you will do so yourself.

📋 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. However, as it is disabled by default, it isn't necessary for users to be aware of the change.