Intentionally leak our Application, so that we DON'T crash on exit (#…

…5629)

We've got a weird crash that happens terribly inconsistently, but pretty
readily on migrie's laptop, only in Debug mode. Apparently, there's some
weird ref-counting magic that goes on during teardown, and our
Application doesn't get closed quite right, which can cause us to crash
into the debugger. This of course, only happens on exit, and happens
somewhere in the `...XamlHost.dll` code.

Crazily, if we _manually leak the `Application`_ here, then the crash
doesn't happen. This doesn't matter, because we really want the
Application to live for _the entire lifetime of the process_, so the only
time when this object would actually need to get cleaned up is _during
exit_. So we can safely leak this `Application` object, and have it just
get cleaned up normally when our process exits.

* [x] I discussed this with @DHowett-MSFT and we both agree this is mental
* [x] I'm pretty sure there's not an actual bug on our repo for this
* [x] I verified on my machine where I can crash the terminal 100% of the time on exit in debug, this fixes it
* [x] I verified that it doesn't introduce a _new_ crash in Release on my machine

src/cascadia/WindowsTerminal/AppHost.cpp

@@ -166,6 +166,24 @@ void AppHost::Initialize()
     // set that content as well.
     _window->SetContent(_logic.GetRoot());
     _window->OnAppInitialized();
+
+    // THIS IS A HACK
+    //
+    // We've got a weird crash that happens terribly inconsistently, but pretty
+    // readily on migrie's laptop, only in Debug mode. Apparently, there's some
+    // weird ref-counting magic that goes on during teardown, and our
+    // Application doesn't get closed quite right, which can cause us to crash
+    // into the debugger. This of course, only happens on exit, and happens
+    // somewhere in the XamlHost.dll code.
+    //
+    // Crazily, if we _manually leak the Application_ here, then the crash
+    // doesn't happen. This doesn't matter, because we really want the
+    // Application to live for _the entire lifetime of the process_, so the only
+    // time when this object would actually need to get cleaned up is _during
+    // exit_. So we can safely leak this Application object, and have it just
+    // get cleaned up normally when our process exits.
+    ::winrt::TerminalApp::App a{ _app };
+    ::winrt::detach_abi(a);
 }
 
 // Method Description: