Add native Test Coverage UI support via Ceedling's gcov plugin

[jake-kim-sndk]

Summary

This adds a Run with Coverage profile to the Testing view. It runs the tests through Ceedling's gcov: task and shows the result in VS Code's built-in Test Coverage UI: the Test Coverage panel, per-file percentages, and line and branch hit counts in the editor.

Ceedling's gcov plugin already writes a gcovr Cobertura report with per-line hit counts, branch coverage and, with newer gcovr, per-function entries, but nothing was reading it. This connects that report to the test coverage API that VS Code finalized in 1.88.

Since 2.0 already moved to the native Testing API with createTestController, adding a TestRunProfileKind.Coverage profile felt like the natural next step. I'm happy to change anything so it fits where you want to take the extension.

What changed

File	What it does
src/gcovrCoberturaReport.ts	New. Turns the parsed report into plain data without depending on vscode. It's split out like ceedlingXmlReport.ts for the same reason: vscode can't be loaded under plain mocha, so a parser inside ceedlingEngine.ts couldn't be unit tested.
tests/unit/gcovrCoberturaReport.test.ts	New. Runs both fixtures through the same for (const version of ...) loop that ceedlingXmlReport.test.ts uses.
tests/fixtures/gcovr-5.0/, tests/fixtures/gcovr-8.6/	New. Real reports rather than hand-written ones (see Testing), named after the gcovr version the way ceedling-1.0.0/ is.
src/ceedlingEngine.ts	Coverage versions of the run entry points, plus reading the report and deleting a stale one.
src/testController.ts	A Coverage run profile (not the default one) and loadDetailedCoverage.
package.json	The new ceedlingExplorer.coverageCommandArgs setting, which defaults to ["gcov:${TEST_ID}"], and the engine bump.

A few things were deliberate:

• Coverage has its own profile and isn't the default. A coverage run rebuilds with instrumentation and is noticeably slower (about 20% on my suite, 13.4s vs 11.2s), so it sits behind its own button instead of slowing down every run.
• coverageCommandArgs is a separate setting rather than a flag on testCommandArgs. The gcov: task isn't a drop-in replacement for test: because it needs the gcov plugin enabled, so if someone has customized one, the other shouldn't quietly change with it.
• A coverage run deletes the previous report before it starts. If the build fails, gcovr never runs, and the old report would otherwise be shown as if this run had produced it. deleteXmlReport already guards against the same thing for test results. The delete happens once per project rather than once per entry, so a later entry that fails to build doesn't throw away the report an earlier entry of the same run produced.

Why the minimum VS Code version goes from 1.71 to 1.88

TestRunProfileKind.Coverage, FileCoverage, StatementCoverage, BranchCoverage and TestRun.addCoverage were all finalized in 1.88 (March 2024). There's no way to do this on the stable API before that, and there isn't a useful fallback either, since without the API there's nowhere to show the coverage.

As far as I can tell, ^1.71.0 was carried over rather than chosen on purpose. It came in with f94c897 (November 2023, a CI and security fix) and stayed the same through the 2.0 rework. Anyone on a version older than 1.88 keeps getting 2.0.1 from the Marketplace, which doesn't have coverage anyway, so they don't lose anything. That said, it's your call. If you'd rather hold this until a release where you're raising the minimum anyway, just let me know.

Paths

This is the part I'd look at most closely, because any mistake here fails the same way: no coverage shows up and nothing reports an error. There were three things to get right.

1. gcovr writes <filename> relative to <source> for files inside its root and as an absolute path for files outside it. Ceedling projects often have both.
2. Before gcovr 8.3, <source> is itself relative. It's just ., which means wherever gcovr ran. gcovr lists this as a known bug (#1037) that was fixed in 8.3.
3. Uri.file() doesn't resolve relative paths, so Uri.file('src/foo.c') becomes file:///src/foo.c.

So the parser is given the directory Ceedling ran in (absPath, which is the cwd in execCeedling) and uses path.resolve(baseDir, source, filename), which handles every combination. path.join doesn't, because path.join('.', '/abs/foo.c') silently drops the leading slash. I first ran into that in another coverage extension that does exactly this. It's the same absPath resolution that runInternal already does for compiler diagnostics, for the same Uri.file() reason.

Testing

• npm run build is clean and npm run test:unit passes 69 tests (53 before, 16 new).
• The fixtures are real reports from Ceedling 1.1.6's gcov plugin. I ran it on a small probe project, using src/Calculator.c from tests/manual plus a lib/Clamp.c one level above the project, once with gcovr 5.0 and once with 8.6. Paths are anonymized to /home/dev/... the same way the ceedling-1.x fixtures are.
• If I put the old path.join logic back, exactly one test fails: gcovr 5.0 with a file inside the root.
• With the gcov plugin enabled, tests/manual now resolves to its real src/Calculator.c. Before the fix it came out as /src/Calculator.c.
• I also installed a packaged VSIX and used it on a real firmware project (gcovr 5.0, with the sources above the Ceedling project). Line and branch coverage show up in the editor and in the Test Coverage panel.

Function rows only show up when gcovr fills in <methods>. gcovr 5.0 leaves it empty while 8.6 fills it in, and the 8.6 fixture covers how those entries are read.

Notes

• I left docs/ReleaseNotes.md alone because it reads like your own write-up and I don't know which version this would go into. CHANGELOG.md and docs/BreakingChanges.md have [Unreleased] entries you can fold in.
• src/testController.ts has an existing TS6138 error (isDevelopmentMode is declared but never read). It's on master too, so I didn't touch it here.

[mkarlesky]

@jake-kim-sndk This is excellent. Thank you so much for your work here.

I have a separate PR #12 that implements some further under-the-hood refactoring with test coverage, integrates support for mixins, and it replaces custom duplicate YAML handling with Ceedling's own. The refactoring is towards some big new features to come. I was planning to finish this up coincident with Ceedling 1.2.0 (coming out very soon).

Anyhow, what I propose is that we merge your PR into #12 with some necessary rework, and bundle this all up to be published when Ceedling 1.2.0 is published. I'd like to also add support for the ReportGenerator option to complement gcovr as it also can produce a Cobertura report (and it's fairly popular in Windows-centric development).

[jake-kim-sndk]

Thanks for your consideration.
I'll retarget destination to #12 and resolve necessary conflicts. Thanks.