[release/6.0] Fix calling NLS with Cultures has alternative sort names

[github-actions]

Fixes#61977
Backport of #61992 to release/6.0

/cc @tarekgh

Customer Impact

This issue is a regression from .NET 5.0 when getting the supported codepages for cultures. This regression is causing failures in the SQL clients which upgraded to .NET 6.0. Here are some links demonstrating such failures:
dotnet/SqlClient#1319 (comment)
dotnet/SqlClient#1396 (comment)
dotnet/efcore#26812 (comment)

The regression happens only with a small set of cultures having alternative sorts (more details about that are below) and only happens on Windows.

Details:
In .NET we depend on the ICU library for globalization. There are some cultural properties which are not supported by ICU. Example of that culture's ANSI codepage. For such properties, we used to hardcode the values in .NET 5.0. In .NET 6.0 when running on Windows OS, we started to call Windows to get a better-updated value.
Usually, cultures support one collation behavior. Some cultures support more than one collation behavior though. For example, the Spanish culture es-ES supports alternative traditional collation es-ES_tradnl. Internally we have two names for the cultures. These two names will have the same value in the usual cases. But the names will differ only with the cultures that have alternative sorts. One name is the normal culture name like es-ES_tradnl. The second name which we'll use when calling ICU like es-ES@collation=tradnl.
The bug we have in .NET is when calling Windows to get the properties like the ANSI codepage, we mistakenly used the name we use to call ICU instead of using the normal culture name. That causes the call to fail, and we return a zero value for the codepage. The problem happens only with the cultures which have alternative collation. Here is the list of such cultures:

 de-DE_phoneb
es-ES_tradnl
hu-HU_technl
ka-GE_modern
ja-JP_radstr
x-iv_mathan
zh-CN_phoneb
zh-CN_stroke
zh-HK_radstr
zh-MO_radstr
zh-MO_stroke
zh-SG_phoneb
zh-SG_stroke
zh-TW_pronun
zh-TW_radstr

The fix is simple that is using the correct name when calling Windows.

Testing

The change is merged to main branch and passed all regression tests. Added a specific test to catch the reported problem. Also, manually checked all culture names to ensure the fix will work fine with all cultures.

Risk

The risk is low as the change is scoped to Windows and the change is using the correct culture names which work fine with Windows. I cannot see this change can cause any problem.

[ghost]

Tagging subscribers to this area: @tarekgh, @safern
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Backport of #61992 to release/6.0

/cc @tarekgh

Customer Impact

Testing

Risk

Author:	github-actions[bot]
Assignees:	-
Labels:	area-System.Globalization
Milestone:	-

[tarekgh]

CC @ericstj@danmoseley for awareness.

CC @safern as he was the one reviewed the original change.

[danmoseley]

@tarekgh thanks for the ping, I agree this mails sense for you to submit to tactics.

[ericstj]

Marking as NO MERGE until branch is open.

[tarekgh]

Approved by @SteveMCarroll