Unit tests won't launch in win-scons CI environment

[NQNStudios]

I'll add more info to this later detailing what I know about the problem and fixes I've tried.

[NQNStudios]

1. The first thing I suspected to be causing this problem, is that the CI is calling build/bin/boe_test.exe with a working directory of build/test. DLLs are copied to build/test but not build/bin, so this is calling a copy of the binary within a different directory than the DLLs and input files. I don't know if Windows executables load DLLs from the working directory, or from the directory they are in. In a branch, I've fixed this, but the problem didn't go away.
2. I noticed in the CI logs, some DLLs are installed into build/test after the tests attempt to run and fail.

Install directory: "rsrc\fonts" as "build\rsrc\fonts"
Install directory: "rsrc\graphics" as "build\rsrc\graphics"
Install directory: "rsrc\strings" as "build\rsrc\strings"
Install file: "build\bin\boe_test.exe" as "build\test\boe_test.exe"
Install file: "C:\vcpkg\packages\boost-filesystem_x64-windows\bin\boost_filesystem-vc142-mt-x64-1_84.dll" as "build\test\boost_filesystem-vc142-mt-x64-1_84.dll"
Install file: "C:\vcpkg\packages\boost-system_x64-windows\bin\boost_system-vc142-mt-x64-1_84.dll" as "build\test\boost_system-vc142-mt-x64-1_84.dll"
Install file: "C:\vcpkg\packages\brotli_x64-windows\bin\brotlicommon.dll" as "build\test\brotlicommon.dll"
Install file: "C:\vcpkg\packages\brotli_x64-windows\bin\brotlidec.dll" as "build\test\brotlidec.dll"
Install file: "C:\vcpkg\packages\bzip2_x64-windows\bin\bz2.dll" as "build\test\bz2.dll"
Install directory: "test\files" as "build\test\files"
Install file: "C:\vcpkg\packages\libflac_x64-windows\bin\FLAC.dll" as "build\test\FLAC.dll"
Install file: "C:\vcpkg\packages\freetype_x64-windows\bin\freetype.dll" as "build\test\freetype.dll"
mkdir "build\test\junk"
Install file: "C:\vcpkg\packages\libogg_x64-windows\bin\ogg.dll" as "build\test\ogg.dll"
Install file: "C:\vcpkg\packages\openal-soft_x64-windows\bin\openal32.dll" as "build\test\openal32.dll"
os.chdir('build\\test')
run_tests(["build\test\passed"], ["build\bin\boe_test.exe"])
os.chdir('D:\\a\\cboe\\cboe')
Install file: "C:\vcpkg\packages\sfml_x64-windows\bin\sfml-audio-2.dll" as "build\test\sfml-audio-2.dll"
Install file: "C:\vcpkg\packages\sfml_x64-windows\bin\sfml-graphics-2.dll" as "build\test\sfml-graphics-2.dll"
Install file: "C:\vcpkg\packages\sfml_x64-windows\bin\sfml-system-2.dll" as "build\test\sfml-system-2.dll"
Install file: "C:\vcpkg\packages\sfml_x64-windows\bin\sfml-window-2.dll" as "build\test\sfml-window-2.dll"
Install file: "C:\vcpkg\packages\libvorbis_x64-windows\bin\vorbis.dll" as "build\test\vorbis.dll"
Install file: "C:\vcpkg\packages\libvorbis_x64-windows\bin\vorbisenc.dll" as "build\test\vorbisenc.dll"
Install file: "C:\vcpkg\packages\libvorbis_x64-windows\bin\vorbisfile.dll" as "build\test\vorbisfile.dll"
Install file: "C:\vcpkg\installed\x64-windows\bin\zlib1.dll" as "build\test\zlib1.dll"
scons: done building targets.

This is bizarre and seems like a definite problem. Not knowing the Scons-correct way to make the test subprocess happen after every installation is finished, I tried making the tests run in an atexit handler, so they're guaranteed to run after all the DLLs are in the proper directory. Wildly, this still didn't work.

---

I can't say for sure that my attempted fixes were perfect--it's possible that the problem is 1) and/or 2), and I had failed to fix them properly. So if anyone else looks at this issue, don't assume it would be a waste of time to retrace my steps there.

The next course of action, I think, is to use dumpbin /dependents on the win-vs64 test executable to see which DLLs it needs and which ones are in the output folder where it runs. Then also use dumpbin /dependents and dir on the win-scons binary, because something must be different between the two of them (win-vs64 works, win-scons doesn't.)

That said, we have win-vs64 running the unit tests correctly, which is good enough for me: Mac, Windows, and Linux each have at least 1 CI job running their unit tests (once #448 is merged). And I've put too many hours into this issue, it can't be worth it when there's lots of other top-priority problems.