refactor: improve locale detection

ECMA-402 support in Node.js should be reliable now, as it's building
with full-icu by default since Node.js 13. So I made it the first
choice.

Actually, I'm not even sure if the remaining variables are still useful.
But if they are used, here are my modifications:

- As for POSIX environment variables, I chose `LC_MESSAGES` over
`LC_CTYPE`, as it better reflects the purpose of the usage (we are using
the detection result to show prompt messages).
- I removed `LANGSPEC` because I can't find any documentation of it except
for one single mention in Wikipedia. I can't find any real usage of it
on my Windows machine.
- As we no longer use `LC_CTYPE`, it seems that `C` is no longer a
possible value for `shellLocale`, so I removed the fallback check logic.

If no more bug reports of Windows users are received in the coming
months, I think we can remove the TODO comment entirely.

utils/getLanguage.ts

@@ -43,17 +43,16 @@ interface Language {
 
 function getLocale() {
   const shellLocale =
-    process.env.LC_ALL ||
-    process.env.LANG || // Unix maybe
-    process.env.LC_CTYPE || // C libraries maybe
-    process.env.LANGSPEC || // Windows maybe
-    Intl.DateTimeFormat().resolvedOptions().locale || // Node.js - Internationalization support
-    'en-US'
+    Intl.DateTimeFormat().resolvedOptions().locale || // Built-in ECMA-402 support
+    process.env.LC_ALL || // POSIX locale environment variables
+    process.env.LC_MESSAGES ||
+    process.env.LANG ||
+    // TODO: Windows support if needed, could consider https://www.npmjs.com/package/os-locale
+    'en-US' // Default fallback
 
   const locale = shellLocale.split('.')[0].replace('_', '-')
 
-  // locale might be 'C' or something else
-  return locale.length < 5 ? 'en-US' : locale
+  return locale
 }
 
 export default function getLanguage() {