Fix calling NLS with Cultures has alternative sort names

[tarekgh]

Fixes#61977

In .NET 6.0 and when running on Windows, we have switched to call NLS to get some properties which are not available with ICU. CultureInfo.TextInfo.ANSICodePage is a good example of that. When we are calling NLS in such cases we use the internal culture name stored in _sWindowsName. The problem here is when using cultures which have alternative sorts (e.g. es-ES_tradnl) such names will be stored as es_ES@collation=tradnl to be used when calling ICU too. If this name is used with NLS, the calls will fail. The fix here is to use the name that works with Windows which is stored in the field sRealName instead. On NLS mode, _sWindowsName is same as _sRealName so this change shouldn't affect this mode.

[ghost]

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

Issue Details

---

In .NET 6.0 and when running on Windows, we have switched to cl NLS to get some properties which are not available with ICU. CultureInfo.TextInfo.ANSICodePage is a good example of that. When we are calling NLS in such cases we use the internal culture name stored in _sWindowsName. The problem here is when using cultures which have alternative sorts (e.g. es-ES_tradnl) such names will be stored as es_ES@collation=tradnl to be used when calling ICU too. If this name is used with NLS, the calls will fail. The fix here is to use the name that works with Windows which is stored in the field sRealName instead. On NLS mode, _sWindowsName is same as _sRealName so this change shouldn't affect this mode.

Author:	tarekgh
Assignees:	-
Labels:	area-System.Globalization
Milestone:	-

[tarekgh]

@safern could you please help reviewing this one?

[safern]

LGTM, makes sense!

[tarekgh]

I logged the issue for the unrelated CI failure.

[tarekgh]

/backport to release/6.0

[github-actions]

Started backporting to release/6.0: https://github.com/dotnet/runtime/actions/runs/1517839642