Add UseConsistentParameterSetName Rule

[liamjpeters]

PR Summary

Add UseConsistentParameterSetName rule to detect potential parameter set issues

Parameter set names are case-sensitive in PowerShell (unlike most other elements), which can lead to runtime errors and unexpected behavior when not handled correctly.

The rule performs five key validations:

1. Missing DefaultParameterSetName - Warns when parameter sets are defined but no default is specified
2. Duplicate parameter declarations - Detects parameters declared multiple times in the same parameter set
3. DefaultParameterSetName case mismatch - Warns when the DefaultParameterSetName matches the text but not case of a defined parameter set.
4. ParameterSetName case inconsistency - Validates consistent casing across all references to the same parameter set
5. Invalid characters - Prevents newline characters in parameter set names.

Fixes #396 with the exception of ParameterSets that don't have at least one unique parameter.

This won't help with Dynamic Parameters.

PR Checklist

• PR has a meaningful title
  • Use the present tense and imperative mood when describing your changes
• Summarized changes
• Change is not breaking
• Make sure all .cs, .ps1 and .psm1 files have the correct copyright header
• Make sure you've added a new test if existing tests do not effectively test the code changed and/or updated documentation
• This PR is ready to merge and is not Work in Progress.
  • If the PR is work in progress, please add the prefix WIP: to the beginning of the title and remove the prefix when the PR is ready.

[andyleejordan]

We need to verify our understanding of parameter sets to review this better, we'll get back to it Liam!

[bergmeister]

@liamjpeters can you resolve merge conflict please so we can run CI?

[liamjpeters]

@liamjpeters can you resolve merge conflict please so we can run CI?

Done. If you approve the CI runs, I'll fix any issues that may have cropped up

[bergmeister]

@liamjpeters can you resolve merge conflict please so we can run CI?

Done. If you approve the CI runs, I'll fix any issues that may have cropped up

Thanks for quick turnaround, approved just now. You should be able to run the tests in your fork as well btw (at least that was the case when we were in Azure DevOps before we moved CI to GitHub). If not, let me know, we can look into enabling that generally or just for you as a regular contributor

[bergmeister]

since it's a new rule and Andy's comment indicated we aren't 100% sure on everything, might be best to start with not enabled by default in first release and pending user feedback enable it by default later. My experience over the last years is that users find surprisingly many edge cases even in simple rules and had to learn this the hard way.

[liamjpeters]

ok cool. I'll definitely take that on board and learn from your hard-earned experience. I'll get this changed to an optional rule over the weekend.

[liamjpeters]

@liamjpeters can you resolve merge conflict please so we can run CI?

Done. If you approve the CI runs, I'll fix any issues that may have cropped up

Thanks for quick turnaround, approved just now. You should be able to run the tests in your fork as well btw (at least that was the case when we were in Azure DevOps before we moved CI to GitHub). If not, let me know, we can look into enabling that generally or just for you as a regular contributor

The triggers for the CI are a push or PR to main. My fork is old enough that it still has master as the default branch and I'm honestly not too sure how to change it 😅. Even still, I probably wouldn't do little PRs for testing on my fork. I can, and do, run the tests locally (on windows at least). It'd need workflow_dispatch as a trigger to enable the "Run Workflow" option in the GUI.