fix(debug): Print stack trace for unhandled win32 exceptions to debug log

[slurmlord]

Overview

This change adds a process-wide win32/se exception filter that is invoked when an unhandled exception occurs. This filter logs the stack trace of the exception to the debug log and lets the rest of the exception handling proceed, typically by terminating the process.
This filter does not get invoked when a debugger is attached to the process.

Background

The current implementation uses _set_se_translator to get a callback when an unhandled win32 exception occurs, such as an access violation. This callback is then used to log the stack trace for the exception to the debug log.
There are multiple problems with this as currently implemented:

• The code is required to be compiled with /EHa for _set_se_translator to work, which is not currently set (at least not for vs2022). Thus the translator is not invoked and the stack trace is not logged at all. Compiling with /EHa could also have negative performance impacts as per the documentation.
• _set_se_translator works on a per-thread level, so if there is a thread that does not call it and then encounters an exception, the callback is not done.
• The documentation for _set_se_translator explicitly states that things like logging to a file should not be done inside the translator function.

Implementation

This change removes all calls to _set_se_translator from various threads, and replaces them with a call to SetUnhandledExceptionFilter from WinMain for Generals and ZH and CWorldBuilderApp::InitInstance for WorldBuilders. This is process-wide, and applies to all threads. The unhandled exception filter calls the existing DumpExceptionInfo method for logging the stack trace to the debug log, before returning a EXCEPTION_EXECUTE_HANDLER value indicating that the associated exception handler should be executed.
There are other calls to _set_se_translator in the code, but as far as I can tell they are used by the tools and not the game or WorldBuilder. They have been left as is, and since the call to SetUnhandledExceptionFilter is done in WinMain for the games and InitInstance for WorldBuilders it should not change the behavior of the other tools.

Validation

Using a VS2022 build, triggering an access violation, the current main version will crash with no mention of the exception in the debug log. After applying this change the process still crashes, but the stack trace for the access violation is logged before exiting.

[slurmlord]

The callback is basically DEBUG_LOG, so due to the recent newline changes there, this newline is no longer needed.

[OmniBlade]

Might want replicating to at least WorldBuilder to capture exception info there as well, but that can be handled at some later point.

[xezon]

Very nice. Thank you.