Allow overriding of CMakePresets cache variables and arguments

[gcampbell-msft]

This change addresses item #1836.

This changes the behavior of the settings provided by the CMake extension for arguments and environments.

The following changes are proposed:

• Allow various fields that modify configuration, build, and testing, to override CMakePresets environments and arguments.
• Specifically, this includes the following fields that are now supported when using presets, while doing various actions
  • cmake.environment (any cmake command)
  • cmake.configureArgs (configure)
  • cmake.configureEnvironment (configure)
  • cmake.buildArgs (build)
  • cmake.buildEnvironment (build)
  • cmake.buildToolsArgs (build, but specific to the build tool)
  • cmake.ctestArgs (test)
  • cmake.testEnvironment (test)
• With the above changes, we added UI notifications to ensure users are aware of when any of the above settings are possibly overriding settings from their Preset. In general, the UI will appear if they have any setting (from the above list) affecting their configurations.
• Also, we added log statements that will appear in the output that will notify the user as well.

The purpose of this change

The general purpose is to allow for the settings we provide via VS Code, to be used during CMake Presets so that people can temporarily override various settings and cache variables in order to test and investigate their configuration and project set-up.

Screenshots of various functionality.

Project status view:
If there are settings set in any of the above list, the affected configuration will have a UI string to notify the user:

When there are settings that are affecting the configuration, a setting icon will appear that will open the settings to the possible settings that may be affecting the configuration:
.
This will open the settings as such:
.

Additionally, if the settings are removed, then the "override settings applied" text will be removed from the UI.

Status bar:

An * is added to the status bar if the configure preset, build preset, or test preset icons are visible and there are settings (from the above list) set.

Output pane:
There will be a simple text output that indicates that there are settings defined that may affect or override your preset configuration. This will happen for things like configure, build, test, launch, etc.
Here is an example:

[gcampbell-msft]

@snehara99 @benmcmorran @lukka Ping for review. I'd especially like review on the various strings I've modified and added and whether the wording is good, or if I should rework some of them. This includes the strings for tooltips for the command I added, the output text in the output pane, and the text in the project status view.

Other than that, it should be a normal PR review. Thanks!

[lukka]

where are [-T, test] now defined? Are they still being used?

[gcampbell-msft]

They are still being used, however, we are falling back to allowing the user to have control over it. They are now coming from the ctestDefaultArgs (see line 251 in the new code). In package.json, the default values for ctestDefaultArgs are -T, test, --output-on-failure. So, instead of hardcoding this in, we are now allowing the user to modify the default arguments that are always appended to the front of the command.

[kupix]

Fantastic, thank you, although you sounded a bit hesitant @gcampbell-msft that this is a good idea. Here is a clear usecase:

In my CMakePresets.json I have:

  "toolchainFile": "$env{ANDROID_NDK}/build/cmake/android.toolchain.cmake",

On my local machine ANDROID_NDK is /home/xipix/android-ndk-r26c. However when this builds on GitHub Actions, ANDROID_NDK has a different value, controlled by GitHub and subject to change. The change allows me to use CMakePresets.json in CI which improves coherence with developer builds.