std: Don't inline TLS accessor on MinGW

This is causing [issues] on Cargo's own CI for MinGW and given the
original investigation there's no reason that MinGW should work when
MSVC doesn't, this this tweaks the MSVC exception to being a Windows exception.

[issues]: https://github.com/rust-lang/cargo/runs/2626676503?check_suite_focus=true#step:9:2453

library/std/src/thread/local.rs

@@ -162,7 +162,7 @@ macro_rules! thread_local {
 macro_rules! __thread_local_inner {
     // used to generate the `LocalKey` value for const-initialized thread locals
     (@key $t:ty, const $init:expr) => {{
-        #[cfg_attr(not(target_env = "msvc"), inline)] // see comments below
+        #[cfg_attr(not(windows), inline)] // see comments below
         unsafe fn __getit() -> $crate::option::Option<&'static $t> {
             const _REQUIRE_UNSTABLE: () = $crate::thread::require_unstable_const_init_thread_local();
 
@@ -262,28 +262,28 @@ macro_rules! __thread_local_inner {
             fn __init() -> $t { $init }
 
             // When reading this function you might ask "why is this inlined
-            // everywhere other than MSVC?", and that's a very reasonable
+            // everywhere other than Windows?", and that's a very reasonable
             // question to ask. The short story is that it segfaults rustc if
-            // this function is inlined. The longer story is that MSVC looks to
-            // not support `extern` references to thread locals across DLL
+            // this function is inlined. The longer story is that Windows looks
+            // to not support `extern` references to thread locals across DLL
             // boundaries. This appears to at least not be supported in the ABI
             // that LLVM implements.
             //
-            // Because of this we never inline on MVSC, but we do inline on
+            // Because of this we never inline on Windows, but we do inline on
             // other platforms (where external references to thread locals
             // across DLLs are supported). A better fix for this would be to
-            // inline this function on MSVC, but only for "statically linked"
+            // inline this function on Windows, but only for "statically linked"
             // components. For example if two separately compiled rlibs end up
             // getting linked into a DLL then it's fine to inline this function
             // across that boundary. It's only not fine to inline this function
-            // across a DLL boundary. Unfortunately rustc doesn't currently have
-            // this sort of logic available in an attribute, and it's not clear
-            // that rustc is even equipped to answer this (it's more of a Cargo
-            // question kinda). This means that, unfortunately, MSVC gets the
-            // pessimistic path for now where it's never inlined.
+            // across a DLL boundary. Unfortunately rustc doesn't currently
+            // have this sort of logic available in an attribute, and it's not
+            // clear that rustc is even equipped to answer this (it's more of a
+            // Cargo question kinda). This means that, unfortunately, Windows
+            // gets the pessimistic path for now where it's never inlined.
             //
-            // The issue of "should enable on MSVC sometimes" is #84933
-            #[cfg_attr(not(target_env = "msvc"), inline)]
+            // The issue of "should enable on Windows sometimes" is #84933
+            #[cfg_attr(not(windows), inline)]
             unsafe fn __getit() -> $crate::option::Option<&'static $t> {
                 #[cfg(all(target_arch = "wasm32", not(target_feature = "atomics")))]
                 static __KEY: $crate::thread::__StaticLocalKeyInner<$t> =