OrchardCore: CultureInfo should not depend on local computer settings

Describe the bug

When the library sets the culture using new CultureInfo(culture) you can get unexpected results if this is also the system’s culture and data formats were customized. This could be a problem if the server wants one data format for internal administrative use that’s different from the culture’s canonical format.

For example you have an en-US server with date format set to ISO 8601 (this is actually what we have on our CI - this problem is most painful while doing UI tests). Then if you want to display a date in OC with the site set to American locale, it will display it using ISO 8601 which is not what you’d expect. The site’s internationalization should not depend on the local format settings.

To Reproduce

This repro assumes you have Windows 10 with en-US region settings:

Steps to reproduce the behavior on Windows:

1. Go to /Admin/Settings/localization and make sure your site is en-US.
2. Create a new view that contains @T["Date: {0:d}", new DateTime(2022, 02, 21, 12, 0)]
3. Navigate to it, you will see Date: 2/21/2022.
4. Go to Start Menu > Settings > Time & Language > Region > Change data format
5. Change the Short date to “2017-04-05”.
6. Restart the server.
7. Visit the same page again, you will see Date: 2022-02-21.

Expected behavior

You should still see Date: 2/21/2022.

Speculation

I believe the problem can be solved simply by altering OrchardCore.Localization.CultureScope.SetCultures to generate fresh stock cultures. So from this:

        private static void SetCultures(CultureInfo culture, CultureInfo uiCulture)
        {
            CultureInfo.CurrentCulture = culture;
            CultureInfo.CurrentUICulture = uiCulture;
        }

Into this:

        private static void SetCultures(CultureInfo culture, CultureInfo uiCulture)
        {
            CultureInfo.CurrentCulture = new CultureInfo(culture.Name, useUserOverride: false);
            CultureInfo.CurrentUICulture = new CultureInfo(uiCulture.Name, useUserOverride: false);
        }