Install a Vectored Exception Handler[0]. Its sole purpose is to catch
some exceptions (access violations, stack overflows, illegal
instructions and debug breaks - by default, but it can be made to catch
any exception for which a code is known) and run a debugger in response.

This allows W32 glib applications to be run without a debugger,
but at the same time allows a debugger to be attached in case
something happens.

The debugger is run with a new console, unless an environment variable
is set to allow it to inherit the console of the crashing process.

The short list of handleable exceptions is there to ensure that
this handler won't run a debugger to "handle" utility exceptions,
such as the one that is used to communicate thread names to a debugger.

The handler is installed to be called last, and shouldn't interfere
with any user-installed handlers.

There's nothing fancy about the way it runs a debugger (it doesn't even
support unicode in paths), and it deliberately avoids using glib code.

The handler will also print a bit of information about the exception
that it caught, and even more information for well-known exceptions,
such as access violation.

The whole scheme is similar to AeDebug[1] and, in fact, the signal-event
gdb command was originally implemented for this very purpose.

[0]: https://docs.microsoft.com/en-us/windows/desktop/debug/vectored-exception-handling
[1]: https://docs.microsoft.com/en-us/windows/desktop/debug/configuring-automatic-debugging