Test that StringComparers and StringComparisons are kept in sync

[drewnoakes]

These two utility classes should have the same members, with equivalent values. This change adds missing properties to both classes, and adds a test to ensure that they're kept in sync in future.

Checklist

• Is this feature complete?
  • Yes. Ready to ship.
  • No. Follow-up changes expected.
• Are you including unit tests for the changes and scenario tests if relevant?
  • Yes
  • No
• Did you add public API?
  • Yes
    • If yes, did you have an API Review for it?
      • Yes
      • No
    • Did you add <remarks /> and <code /> elements on your triple slash comments?
      • Yes
      • No
  • No
• Does the change make any security assumptions or guarantees?
  • Yes
    • If yes, have you done a threat model and had a security review?
      • Yes
      • No
  • No
• Does the change require an update in our Aspire docs?
  • Yes
    • Link to aspire-docs issue:
  • No

Microsoft Reviewers: Open in CodeFlow

[JamesNK]

What about using a type structure that forces them to be declared together? e.g.

public record KnownComparison(StringComparison Comparison, StringComparer Comparer);

public static class KnownStringFormats
{
    public static readonly KnownComparison ResourceName = new (StringComparison.OriginalIgnoreCase, StringComparer.OriginalIgnoreCase);
   // ... etc
}

// Usage
var resourcesByName = new Dictionary<string, ResourceViewModel>(KnownStringFormats.ResourceName.Comparer);

[drewnoakes]

I think the test failure occurs when the current culture is also the invariant culture. Investigating.

What about using a type structure that forces them to be declared together?

This adds some runtime overhead and makes the call site's code more verbose, so I'm not a fan personally.

[mitchdenny]

This is a good idea.