Site Health: Debug copy field uses site locale, not user locale

[Clorith]

The Debug Information part of the site health element takes the sites locale into account, and allows a user to copy either an English, or a translated version of the information for use when seeking support.

This currently checks the site language, as it was implemented before core supported different locales per user.

This should be updated, as a user looking for localized help is likely to choose their own language over the site language if they should differ.

[azaozz]

Related: #46726.

[Clorith]

46694.patch​ replaces our use of get_locale to instead use get_user_locale, to reflect that this is the user viewing things, so they may have different preferential language options from the site it self.

[desrosj]

While reviewing this, I noticed that there are function_exists() checks for switch_to_locale() and restore_locale(). I confirmed with @Clorith that these were in the plugin version of Site Health for the purpose of supporting older versions of WordPress. These are no longer needed, as all WordPress 5.2 installs will have these functions.

[desrosj]

In 45110:

Site Health: Ensure the user locale is listed in debug information.

This change switches to using get_user_locale() when adding the language to the Site Health debug information to ensure the user’s locale preference is reflected.

Also, function_exists() checks for switch_to_locale() and restore_previous_locale() were required in the plugin to support older versions of WordPress, but they are not required in core/

Props: Clorith, desrosj.
Fixes #46694.