feat(lsp): add "Debug" code lens for test steps (#34742)
The LSP emits "▶ Run Test" / "Debug" code lenses above `Deno.test` calls
(resolved by the `deno.client.test` command in the VS Code extension),
but test steps only had the native test-explorer gutter "play" button —
which can *run* a step but not *debug* it. This is the gap described in
#21664.
## Change
`DenoTestCollector` (in `cli/lsp/code_lens.rs`) now descends into test
function bodies and emits the same "▶ Run Test" / "Debug" code lenses
for each test step:
- `t.step(...)` on the test context, including arbitrarily nested steps
- destructured `step(...)` (e.g. `Deno.test("t", ({ step }) => …)`)
- BDD `it(...)` / `it.only|ignore|skip(...)` inside `describe(...)`
The step-detection logic mirrors the static collector in
`cli/lsp/testing/collectors.rs` (which already powers the test-explorer
tree), reusing its `parse_test_context_param` helper.
## Why filter by the parent test name
`deno test --filter` matches **top-level test names only**
(`TestFilter::includes` is applied per top-level test; steps always run
with their parent). So each step lens filters by its enclosing
**top-level** test name. "Debug" on a step therefore runs its parent
test under the inspector — exactly the same test the gutter "play"
button already runs, but now with the debugger attached and the user
free to set a breakpoint inside the step.
Top-level code lens output is unchanged (the existing
`test_deno_test_collector` unit test and `lsp_code_lens_test`
integration test are untouched).
## Tests
Added unit tests in `cli/lsp/code_lens.rs` covering `t.step`,
destructured `step`, and BDD `it` steps. Run with `cargo test -p deno
--lib lsp::code_lens`.
Closes #21664
Closes denoland/divybot#436
Co-authored-by: divybot <divybot@users.noreply.github.com>
Co-authored-by: Divy Srivastava <me@littledivy.com>
