Client phase 3b: work with BugSplat to make Windows crash reporting more reliable

When the Windows BugSplat client detects its host viewer is crashing, it immediately tries to send a crash report to BugSplat. It may or may not write crash state files to the local filesystem.

The weak link there is that empirically, some large fraction of Windows viewer crashes damage the process so badly that the crash report never makes it to BugSplat.

If the Windows BugSplat client doesn't already write crash state to the filesystem, work with BugSplat to enhance it to do so. Embed, in the Windows watchdog child process, the BugSplat client. When the watchdog process detects that the viewer has terminated involuntarily, coax BugSplat to read the viewer's crash report files and send them right away.

This probably requires library enhancements from BugSplat.

Test Plan

Run the Windows viewer. Force a crash. Observe that the crash report is sent to BugSplat.

Only once this is released into the wild can we obtain statistical confirmation that it resolves the missing crash report problem. We can correlate BugSplat crash reports with our own crash reporting.

Start with the Windows watchdog child process described in issue 3426 and inspect how it detects involuntary viewer termination. Review the BugSplat client integration and determine whether crash state files are written and can be sent from the watchdog. Done means a forced Windows viewer crash produces a BugSplat report, verified by the stated test plan.