Add CodeTour selection range support

[jacklaplante]

What changed

• Add Microsoft CodeTour-compatible selection.start and selection.end domain fields.
• Select and center the configured code range when navigating to a tour step.
• Derive legacy navigation lines and gutter markers from the selection start when line is omitted.
• Record the active editor selection when creating a step from the gutter.
• Preserve selection metadata while editing descriptions, but clear a stale selection when the navigation reference changes.
• Display full range references in the step editor and rendered tour dialog.
• Clamp stale line and character positions to the current document instead of crashing playback.
• Defer file-reference validation until project indexing finishes, preventing false "Invalid Steps" startup dialogs.
• Resolve repository-relative step paths directly before consulting the IDE index, so Rider can validate and open files outside the loaded solution model.
• Add focused parsing and offset-conversion tests and document the feature.

Why

Microsoft's CodeTour format supports code selections, but the IntelliJ plugin currently navigates only to one line. This makes larger explanations hard to connect to their complete implementation and prevents portable VS Code tours from retaining their highlighted ranges.

Developer impact

Existing file / line steps behave as before. Tours can now use the standard one-based, end-exclusive shape:

"selection": {
  "start": { "line": 10, "character": 3 },
  "end": { "line": 18, "character": 1 }
}

Creating a step while editor text is selected records the same structure automatically.

Validation

• gradlew test
• gradlew buildPlugin
• gradlew verifyPlugin

All completed successfully with the project's configured Java 17 toolchain.

The revised plugin was also installed into Rider 2024.3 and verified against a mixed Unity/server repository: startup validation completed with 0 errors, including targets outside the Unity solution.

The Gradle publish-channel expression was also changed to an equivalent unambiguous substringBefore('.') form because the original expression no longer compiles with the current Gradle Kotlin DSL.