Fix case-insensitive JSON deserialization of enum member names

[PranavSenthilnathan]

Fixes #110745

The JSON serializer supports deserializing an enum case-insensitively from the C# enum member name even when a naming policy is used. For example, consider the following enum:

enum MyEnum { EnumValue }

If JsonNamingPolicy.SnakeCaseLower is specified, then "enum_value" will be deserialized to MyEnum.EnumValue (this is case-sensitive, so deserializion of "Enum_value" will throw). In addition, "EnumValue" also will be deserialized to MyEnum.EnumValue because it is the name of the member (this is case-insensitive so "enumValue" will also be deserialized).

However, there is a regression in .NET 9.0 when the enum member name is the same as the name from the naming policy:

var options = new JsonSerializerOptions();
options.Converters.Add(new JsonStringEnumConverter(JsonNamingPolicy.SnakeCaseLower));

// Both work in .NET 8.0 but throw in .NET 9.0
Console.WriteLine(JsonSerializer.Deserialize<MyEnum>("\"Example\"", options));
Console.WriteLine(JsonSerializer.Deserialize<MyEnum>("\"Another_Example\"", options));

enum MyEnum
{
  // C# name: "example"
  // lower snake-case: "example"
  example,

  // C# name: "another_example"
  // lower snake-case: "another_example"
  another_example
}

Note that the enum member name for both members is the same as the lower snake casing.

The regression was introduced in #105032 which added the JsonStringEnumMemberName attribute allowing custom names to be specified for enum members. That change added a new design for the converter which essentially uses the custom name, the naming policy derived name, and/or the C# member name as the key to figure out which C# enum value to deserialize to. This edge case was not covered because the C# member name and the naming-policy derived name both would have the same key and thus the C# member name was not inserted into the lookup.

The change in this PR fixes this by always adding both the naming-policy key and the C# member name key regardless of whether they are the same. There were no tests for this specific code path, so new tests have been added to cover this case now.

Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.

[eiriktsarpalis]

I'll admit I find the use of the term "superset" to be somewhat confusing in this context. I would recommend renaming to something like MatchesWith or ConflictsWith. Perhaps also rename field1 and field2 to current and other to better emphasize what field is stored and which one is being added.

[eiriktsarpalis]

Looks great apart from a minor naming nit pick. Because it's a regression, this should also be backported to release/9.0.

[eiriktsarpalis]

/backport to release/9.0

[github-actions]

Started backporting to release/9.0: https://github.com/dotnet/runtime/actions/runs/13082434283