Suggestion: IDE0079 (Remove unnecessary suppression) allow .editorconfig to support prefixes

Analyzer

Diagnostic ID: IDE0079

Describe the improvement

Today in configuring this rule, .editorconfig allows all, none, or a comma-delimited list of analyzer IDs. In the comma list, it also supports category: for all things in a specific category. I propose we add support for prefix: to this configuration, e.g.

dotnet_remove_unnecessary_suppression_exclusions = prefix:RCS
# Multiple example:
dotnet_remove_unnecessary_suppression_exclusions = CA1009,CA1063,prefix:RCS

This would ignore all RCS* rules, e.g. RCS0001, RCS0002, etc.

Additional context

The intent of IDE0079 is great, but the reality is that different team members may have more invasive/noisy analyzers running (for example, I run additional heap and allocation analyzers), so the experience between team members is inconsistent and can easily make edit/reverse commits (achieving only noise) making these go back and forth. It's apparent to me that the .editorconfig support was meant to address this case, but this would improve it. When we're including analyzers or not between team members, it's likely via an extension one person has but not another. Those extensions don't often have one big category for all analyzers...but they do have a common prefix.

If we allowed IDE0079 to be turned off in that way, it'd save a lot of time in both ignoring each one and the edit/reverse steps to get there. Importantly: the problem with this analyzer doesn't happen on the person's machine using additional analyzers, it happens on everyone else's machine. That makes the user experience a few steps away to get to the desired team-wide result. If we had a prefix route like this, it'd be a better way to address it than repeating such discussions whenever a new analyzer is added, suppressed, removed by someone seeing it in IDE0079, original adder seeing it, syncing with team mate, adding to .editorconfig, etc. Repeating that process results in a negative experience overall, so I think it'd be great to better address it and maintain the utility IDE0079 provides.