[mtnmbr]

Test files in nested folders (e.g. tests/unit/math/signal_processing/test_pi_blackbox.c) are all listed as flat siblings in the Testing view, which gets crowded in larger projects.

This adds an opt-in setting, ceedlingExplorer.testFileHierarchy (default false, so existing behavior is unchanged). It nests test files under one node per folder of their path.

• Works with prettyTestFileLabel: with it on, files show as pi_blackbox. With it off, files show as test_pi_blackbox.c, without the path, since the folders above already show it.
• prettyTestLabel keeps working on the test functions.
• Running a folder runs each of its test files, file by file, the same way "Run All" does. Debugging a folder debugs its first file.
• Folder nodes point to their directory, so "Go to Test" reveals the folder in the Explorer.
• The grouping is a pure, vscode-free module with unit tests (tests/unit/testFileHierarchy.test.ts).

Screenshots

	prettyTestFileLabel: true	prettyTestFileLabel: false
testFileHierarchy: false
testFileHierarchy: true

Testing

• npm run test:unit: 58 passing, 5 of them new.
• Tried by hand on a Ceedling 1.1 project with test files nested several folders deep, with every combination of the two pretty-label options.

tsc -p tsconfig.json --noEmit reports one error that's already on master: the isDevelopmentMode property in testController.ts is declared but never read. This change doesn't touch it.

[mkarlesky]

@mtnmbr This is nice work. Thank you. Could you look at retargeting your PR to the next_version branch? We've done a lot to mature this repository, but we haven't gotten to documenting how to contribute. The convention is that master is the latest release plus patches. next_version is the next major or minor release. 2.1.0 is living in next_version. A ton of changes have happened over there, and I think your PR would be a natural addition to that work.

The feature documentation for 2.1.0 is no longer in the README. It's gotten way too big. But, the not-yet-publicly-announced documentation is available and includes some developer docs within the help section.

[mtnmbr]

@mkarlesky Thanks! I've rebased the changes onto next_version and also changed the merge target :)

[mtnmbr]

I've chosen the default for this to be false in order to maintain backwards compatibility. If the next_version changes are bringing other major features/changes to the UI it might also be an option to set this to true.

Other test_views in VSCode atleast have this behaviour on by default.