PR Summary

Fixes#1237
cc@Jaykul
In PSSA 1.17.1 and 1.18.1 I went through 3 test cases of using the following expressions as a custom rule name returned in theDiagnosticRecord of a custom rule:

• $MyInvocation.MyCommand.Name (the name of the function name that returns theDiagnosticRecord)
• '$MyInvocation.InvocationName (same as above but fully qualified, i.e. module name pre-pended to it
• A custom string

All those scenarios are possible in both versions but when the-IncludeDefaultRules switch was used, then in PSSA 1.17.1 the 2nd test case and in PSSA 1.18.0 the 1st and 3rd test case were not working because PSSA throws a red-herring error. This PR makes PSSA not throw an error any more and therefore enabling all 3 scenarios.
The check that used to throw the error tried to check the rule name in the suppression against the available rule names. Unfortunately the conditional logic itself is a bit broken (this is why the errors only surfaced when the-IncludeDefaultRules was used due to properties likeScriptAnalyzer.Instance.ScriptRules not being null any more). The problem with the check is that only at runtime will we know the returnedRuleName of theDiagnosticRecord. People are encouraged to use expressions that mirror the function name that returns theDiagnosticRecord so that there is a match with whatGet-ScriptAnalyzer returns but the reality is that people can return what they want and actively want to do so, seehere. Therefore the check is removed as we cannot determine at this point in time if there is a match or not.
Comparing the functionality with C#: the compiler similarly cannot throw an error either when a suppression attribute does not match an existing code style rule violation, therefore we are removing a feature that was never meant to be complete.

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 notWork in Progress.
  • If the PR is work in progress, please add the prefixWIP: to the beginning of the title and remove the prefix when the PR is ready.