Add creation and validation of ScriptAnalyzer settings files

Review the existing Invoke-ScriptAnalyzer integration and the extension's code-action/UI entry points, then trace how an active editor and workspace folders are handled. The feature is done when users can create PSScriptAnalyzerSettings.psd1 and receive diagnostics from Test-ScriptAnalyzerSettingsFile when that file is open.

Prerequisites

• I have written a descriptive issue title.
• I have searched all issues to ensure it has not already been reported.

Summary

👋

As a module developer, I want to be able to add a ScriptAnalyzer settings file to my project easily, so it's stored alongside my code for consistency.

Something akin to dotnet new editorconfig that gives me some reasonable baseline that I can then tweak to my liking. I want to know what points of configurability are possible, and when there are issues with my settings file.

PSSA, in https://github.com/PowerShell/PSScriptAnalyzer/pull/2176, introduced 2 new cmdlets. The functionality of which could be exposed via PSES in the VSCode Extension.

• New-ScriptAnalyzerSettingsFile - Creates a ScriptAnalyzer settings file populated with all rule names and rule configuration (set to default values). The file has some comment help for each field. The file is always named PSScriptAnalyzerSettings.psd1 so that automatic settings discovery in Invoke-ScriptAnalyzer picks it up without any -Settings parameter needed. Example outputs in this gist.

• Test-ScriptAnalyzerSettingsFile - Validates key elements of a settings file (such as hashtable keys being valid, rule names being recognised etc) and tells you what's wrong and where. Problems are returned as a DiagnosticRecord with a best endeavours extent.

Opening this for feedback (and to raise some awareness of the new cmdlets for feedback on those too 🙂). I would be interested in giving the implementation a go, if the project think it's a reasonable idea (or some version of it) and would be happy with a PR.

Proposed Design

I'm not sure what the correct user experience is. But something like:

• Add a code action/UI to create a new ScriptAnalyzer settings file.

  If there are multiple root folders in the workspace, the user may then need to pick which folder to add it to.

  The cmdlet has a BasedOn parameter that accepts a Preset name, so you could then show a list of presets to base it on - though I'm personally not a fan of the presets.

  When all optional info collected, the New-ScriptAnalyzerSettingsFile cmdlet would be called with the directory -Path where the new settings file should be created.

• When the open file/active editor is called PSScriptAnalyzerSettings.psd1: as well as Invoke-ScriptAnalyzer, also run Test-ScriptAnalyzerSettingsFile against the file and surface any resulting DiagnosticRecords returned.