Windows follow up - Githubissues

PR#9 added initial windows support, with some caveats

[ ] Do we care about Windows 7/8? The original breakpad/crashpad implementation uses Windows named pipes for IPC, but they are TERRIBLE, Windows 10 has had support for unix domain sockets for >4 years now, so I opted to use those instead which made for a dramatically smaller and easier implementation (beyond missing support in eg mio).
[x] We can't handle abort on Windows. crashpad does install a signal handler specifically to catch SIGABRT on Windows, however, I believe that signal is not raised by Rust's std::process::abort, as it uses __fastfail which drastically reduces the usefulness of handling that signal, but still might be worth it for rogue C libraries?
[x] The original breakpad code for both windows and linux allows one to attach multiple handlers, but this is...kind of pointless with the design of the current exception-handler, which is that it doesn't do anything on its own beyond calling the user's callback. If there is a scenario where a user does want to have multiple different handlers, it seems easier for the user to do that themselves, as the majority use case will be to have one handler that (probably?) uses minidumper to write a crash dump before dying.
[x] I added a ServerHandler::message_alloc method to allow users to have their own way of "allocing" the recv buffer instead of always creating a new vec, but I failed to actually use it yet, so, TODO.
[x] Breakpad has some code to add a special stream to the minidump if the exception that was raised was a STATUS_INVALID_HANDLE by enumerating the handle operations via VerifierEnumerateResource and adding all of the operations that were done on the last invalid handle to that stream. However, crashpad doesn't do this at all which I assume means that this extra info was not considered useful?

EmbarkStudios / crash-handling

Windows follow up #10