Add tool mappings to extension settings

[jreineckearm]

Fixes

• [Feature Request]: Locate and verify GDB installation in Arm CMSIS Debugger extension #37
• [Feature Request]: Locate and verify pyOCD installation in Arm CMSIS Debugger extension #38

Changes

• Adds extension settings with the goal to
  • Allow overriding tool executable names with other tools/paths in debug launch configs. Useful if users would like to avoid updating PATH environment variables. And to avoid entering absolute paths in version controlled debug launch configs.
  • Separation of GDB (clients) and GDB servers settings.
  • Allows extending those mappings for portability of other tools (GDBs, GDB servers) not supported out of the box.

Note: This is currently a quick mockup. Functionality not wired in yet.

Screenshots

New set of extension settings

Example of updating the GDB client setting on Windows:

Example of updating the GDB server settings on Windows:

Checklist

[jreineckearm]

Any feedback is welcomed on

• whether you see such settings as useful.
• whether the setting appearance makes sense. Note that we are limited in what we can do on extension settings level.

Based on the feedback, I'll continue with wiring this in. Or drop it in favor of different approaches.

[jkrech]

Configuring these settings in the VSCode extension means that they are for all projects of a user.
When running a debug session headless outside of VSCode, would I be able to configure the settings via a file?

[jreineckearm]

Thanks for the feedback, @jkrech !

Configuring these settings in the VSCode extension means that they are for all projects of a user.

Only if you use the "User" settings. You could also make this "Workspace" specific by selecting the corresponding tab.
Then the setting would be stored under the workspace's .vscode/settings.json.

When running a debug session headless outside of VSCode, would I be able to configure the settings via a file?

No, in that case the overrides would have to be managed differently. For example by a variable in the script/framework that drives the test run. Or by assuming the right tool to be on PATH. I wouldn't see it as part of shareable configuration files.

Also note, that the entire scripting/CI story around Arm CMSIS Debugger is still TBD in all its details. Depending on the GDB server tool, you may deal with a standalone runnable tool like pyOCD which wouldn't need any GDB involvement/overhead in CI.

These settings can be rather considered a means to quickly/conveniently change a tool variant without restarting your IDE. Which you would need to do when you update your PATH environment variable.

I could accept though if we go for an IDE-CLI-consistency approach rather than have more convenience in the IDE.

[jreineckearm]

After further discussion, there is at this point little interest in seeing paths getting overridden by extension settings.
Users will have to use absolute paths in launch configurations if they want to use something else than what's coming with the extension or what's on path.
Mockup should be available through this PR in case we want to resurrect the approach at some point in future. Closing draft PR.