Validation for VS Code settings

[Bob Brown]

Feature Request

In package.json we write a lot of metadata to describe what valid values for our settings look like. VS Code will squiggle settings that don't comply with the validation to let the user know, but it will send the invalid values to us until the user corrects the issues (if they ever do).

In src/LanguageServer/settings.ts a lot of our settings are retrieved with a simple call to super.Section.get<T>. This function call does not do any validation and it also does not cast values to the correct type as you might expect. It simply assumes that the value is of the type you request, but it actually may not be!

We are already doing some validation in the language server, but it would be best to do at least the enum and type validation in the TypeScript code. If it makes sense, we could move all validation to TypeScript so that the settings values can always be assumed to be valid everywhere in the codebase.

[Bob Brown]

And to clarify, the expected result of asking for the value of a setting with an invalid value in it is to return the value of the setting at the next closest settings level above the current level that has a valid value (Default is guaranteed to be valid). Folder -> Workspace -> User -> Default.

ex: the value of C_Cpp.autocomplete in .vscode/settings.json (Folder level) is 'bogus'. So we inspect the value at the Workspace level. If that is invalid, we inspect the value at the User level. If that is invalid, we take the Default value. Some example usage of the inspect<T> API can be found in src/LanguageServer/settingsTracker.ts