Backport of #111032 to release/9.0-staging

/cc @matouskozak

This PR reverts the previous change to preserve the full (specific = language-region) culture locale format.

Customer Impact

• Customer reported
• Found internally

This issue is impacting iOS scenarios which rely on device locale region, such as, displaying local currencies or other regional information. Before this change, only the language was retrieved to set CultureInfo.CurrentCulture and the region was omitted.

Some of the issues reported by customers:

• .NET 9 iOS / HybridGlobalization: currency symbols / currency names not available #108958
• Wrong result from CultureInfo.CurrentCulture.Name in iOS #110680
• System.Globalization.RegionInfo.CurrentRegion returns blank values on Maui #110704

(Added after merge):

• iOS CultureInfo.CurrentCulture.DateTimeFormat.ShortDatePattern not getting OS settings #112099

Regression

• Yes
• No

The regression was introduced in #104071 in .NET 9.

Testing

The previous regression change was intentional. This PR adds a test case for asserting that the default current culture is always in specific format. However, we encountered unexpected behavior on iossimulators running on the CI lab machine thus we disabled the new test case until #111501 gets resolved. We verified locally that the behavior is correct.

Risk

Medium

This change might require customers to change their app logic if they made changes to work around this issue introduced in .NET 9. Note, the behavior is correct in .NET 8.

Additionally, we encountered that for some .NET BCL (e.g., SqlString), the default culture set on device might cause crashes in the libraries code due to #111395. However, these crashes are possible to trigger in .NET 8 iOS apps as well as in apps on other platforms if the user's device locale is not part of the https://github.com/dotnet/runtime/blob/main/src/libraries/System.Private.CoreLib/src/System/Globalization/IcuLocaleData.cs.

IMPORTANT: If this backport is for a servicing release, please verify that:

• The PR target branch is release/X.0-staging, not release/X.0.

Package authoring no longer needed in .NET 9

IMPORTANT: Starting with .NET 9, you no longer need to edit a NuGet package's csproj to enable building and bump the version.
Keep in mind that we still need package authoring in .NET 8 and older versions.