Consider additional FxCop rules to enable

[javiercn]

This is a follow up issue from #9620 which added the infrastructure to enable some basic FxCop rules on the repository.

We want to come up with a list of issues so that we can discuss and decide which ones we want to enable and which ones we don't think add value or are not generally applicable enough to a repository this size.

The approach will be to propose a few rules at a time and introduce them based on general agreement so that we can progressively enable the rules we care about.

[javiercn]

https://github.com/dotnet/roslyn-analyzers/blob/master/src/Microsoft.CodeAnalysis.FxCopAnalyzers/Microsoft.CodeAnalysis.FxCopAnalyzers.md

[Pilchie]

I believe @JamesNK proposed the globalization rules about using stringcomparers, Ordinal, etc as a good first step, and a case where we have already had some bugs to fix.

[JamesNK]

The other good validation is requiring ConfigureAwait(false) on awaits in projects that could run outside of ASP.NET Core. I don't know whether we have any of those in this repo.

(The .NET SignalR client doesn't count as it has its own strategy to avoid the need for ConfigureAwait(false))

[mkArtakMSFT]

Putting this back to Next Sprint Planning in favor of #27631, as this will help community be successful with our repo quicker.

[pranavkm]

Quick note, we should be targeting NetAnalyzers that's part of the .NET SDK: https://docs.microsoft.com/en-us/visualstudio/code-quality/migrate-from-fxcop-analyzers-to-net-analyzers?view=vs-2019