Process/send etw rundown events only during graceful shutdown and not…

… during process detach (a form of abrupt shutdown) (#27238)

Longer-term fix for https://github.com/dotnet/coreclr/issues/27129:
- Etw rundown events sent during process shutdown are currently (and have for a long time) been sent during process detach. By that time, all other threads have been abruptly terminated by the OS, and as a result the state of the system is fundamentally unpredictable.
- In this particular case, locks have been orphaned by threads that have been abruptly terminated, so taking locks is not feasible during processing of rundown events, and if acquiring locks were to be avoided based on such knowledge (not recommended, this would get messy), we'd have to resort to providing information that would not accurately reflect the state, in the events
- I consider any situation where process detach occurs before an opportunity to handle graceful shutdown (that is, the runtime is unaware that a shutdown is about to happen and does not have an opportunity to handle shutdown prior to process detach (before the OS already shuts some things down)), then that is abrupt shutdown and in that scenario all bets are off - in the case of this change, etw rundown events would not be sent
- This change has the following effects:
  - Graceful shutdown such as returning from `Main` or `Environment.Exit()` will send rundown events very slighly earlier than before. Background threads will still be running and there may be other etw events interspersed among rundown events and sent after rundown events.
  - On Windows, Ctrl+C and Ctrl+Break are not handled by the runtime and by default result in abrupt termination. The only indication the runtime gets is the process detach event, by which time the OS has already terminated all other threads
    - When these events are not handled (by the runtime or by the app), this is an abrupt shutdown scenario and rundown events will not be sent
    - When these events are handled by the app and canceled along with `Environment.Exit()`, that converts these events into graceful shutdown (see above). If an app handles these events and chooses to not cancel the event, the event remains unhandled and leads to abrupt shutdown (see immediately above).
  - On Unixes, there is no significant change. SIGTERM is graceful shutdown as described above and there are no similar issues of abrupt shutdown.
- There is an option of sending rundown events upon process detach (when we don't have an opportunity to do so gracefully), but as I described above that will get messy and is not a path that we should be headed down

src/vm/ceemain.cpp

@@ -1321,18 +1321,15 @@ void STDMETHODCALLTYPE EEShutDownHelper(BOOL fIsDllUnloading)
     // Used later for a callback.
     CEEInfo ceeInf;
 
-    if (fIsDllUnloading)
+    if (!fIsDllUnloading)
     {
         ETW::EnumerationLog::ProcessShutdown();
-    }
 
 #ifdef FEATURE_PERFTRACING
-    if (!fIsDllUnloading)
-    {
         EventPipe::Shutdown();
         DiagnosticServer::Shutdown();
-    }
 #endif // FEATURE_PERFTRACING
+    }
 
 #if defined(FEATURE_COMINTEROP)
     // Get the current thread.