Put DLLs in bin so a built program can load them

[tamnd]

Fixes #331.

An install put KGENCompilerRTShared.dll in lib/, along with every other shared library, because the default path is lib/ plus whatever the platform calls a shared library. Nothing on Windows can load a DLL from there.

The compiler itself was fine, because it hands the loader an absolute path it read out of its own configuration. A program that mojo build produced has no configuration to read. It imports the DLL by name, and the Windows loader looks in the directory the program started from, then the system directories, then along PATH, and never in a sibling of the program's own directory. There is no rpath to say otherwise. So the program died with 0xC0000135 and no message, and the only fix a user had was to copy the file out of lib/ by hand.

sharedLibPath now asks the name rather than the host. A .dll goes in bin/ and everything else stays in lib/, which keeps it one question with one answer and leaves Linux and macOS exactly where they were. Import libraries are not affected and stay in lib/, since a linker reads those at a path it is handed and does not go looking.

bin/ is also already where the two other runtime DLLs go in the release archive, for the same reason, so this makes the three of them agree.

Verified on a Windows host against a staged install that has nothing in lib/ but the import library and std.mojoc, and with MODULAR_HOME, MODULAR_MOJO_MAX_PACKAGE_ROOT and MODULAR_MOJO_MAX_IMPORT_PATH all unset:

=== mojo run, no environment ===
hello from a windows build
RUN_JIT_RC=0
=== mojo build, no environment ===
BUILD_RC=0
=== run built exe, bin on PATH, no dlls in cwd ===
hello.exe
hello.mojo
hello from a windows build
RUN_EXE_RC=0

That last one is the case that did not work before. The directory holds only the source and the exe the compiler just produced.

Stacked on #330, so the diff here is the one commit once that lands.

Part of #319.