Support running btests on Windows

[timwoj]

This PR covers the majority of the changes that need to happen to the btest script in order to run tests on Windows. There's a few known issues I'll go into at the end. The big differences here are:

• Switching to the multiprocess module instead of the built-in multiprocessing module, since the default one has some problems with pickling our internal types.
• Changing executing processes on Windows to wrap them in a simple bash script, which lets them run correctly under msys2 (the bash environment installed with Git on Windows).
• Passing data from the test manager down into the child processes via a proxied dictionary. mulitprocess on Windows doesn't seem to like our use of globals here and complains that it can't find objects. The proxied dictionary works around this, and is probably the more correct way of doing this anyways.

Known issues:

• Running tests against debug builds hits an assertion down in the Windows OS libraries. I'm pretty sure this is a libkqueue bug, and opened Closing a file descriptor on Windows might cause an assertion mheily/libkqueue#151 to have them investigate. The easy work-around is to not close the event_queue file descriptor in iosource_mgr, and that can be used for testing.
• Shutting down a run with the -j flag with ctrl-c doesn't work right. There's something different about signal masking on Windows. I spent a day trying to figure this one out and haven't solved it yet.
• There's a problem with pickling our internal types using the dill library used by multiprocess that changes that internal ID stored for the types. run_cmdseq previously used isinstance to check whether a command being run was a CmdSeq but because the type IDs are different it was returning false (on all platforms). There's currently a work-around where we just check the type name, but it's likely possible to fix this via implementing custom pickling methods for those types.

These changes will require some modifications to the Zeek tree to work right as well, but this PR is independent of those.

[ckreibich]

This must have been pretty darn painful. Just a few quick comments here as you're finalizing this.

[awelzel]

I've made a bit of a pass.

[awelzel]

Switching to the multiprocess module instead of the built-in multiprocessing module, since the default one has some problems with pickling our internal types.

From the naive side: Is there something we fix/work-around in the types involved? Adding non-stdlib dependency when there wasn't one before seems unfortunate to me.

[timwoj]

I rebased and squashed down all of the fixup commits. I'm down to just two btests failing:

• tests.diag-file: This one looks like the .stdout and .stderr files get reset between commands run (meaning each time a bash script is fired up), which shouldn't be happening. This causes the output from one the internal btest commands to get lost, which the tests requires for success.
• tests.environment: This one fails because the test calls pwd in the middle of it and compares it to the testbase value read from btest.cfg. On Windows, pwd will return a POSIX-style path (so /c/...) whereas btest currently uses pseudo-Windows-style paths internally (C:/...). It's making me want to switch everything over to use POSIX-style paths since it would help with some consistency between POSIX and Windows in other places, but the last time I tried to do that everything went south quickly.

I'll look over the rest of the comments above after I get back from the holiday break.

[timwoj]

From the naive side: Is there something we fix/work-around in the types involved? Adding non-stdlib dependency when there wasn't one before seems unfortunate to me.

Prior to switching over to the other library, I did attempt to fix the types it was failing on. It turns into a game of whack-a-mole pretty fast, with one type after another failing for varying reasons. I got fairly far into it and then ran into a type that I couldn't figure out how to fix, and figured there had to be a better way to go about it than manually fixing every type and hoping I didn't miss something.