Link against the runtime import library on Windows

[tamnd]

Fixes #327.

mojo build on Windows stopped at the link step:

lld-link: error: C:\tmp\mojohome6/lib/KGENCompilerRTShared.dll: bad file type. Did you specify a DLL instead of an import library?
mojo.exe: error: failed to link executable

mojo-build.cpp put config.getCompilerRTPath() on the linker command line. That is lib/ plus whatever the target platform calls a shared library, so targeting Windows it is the DLL, and a COFF linker cannot read one. The list of names a Windows shared library defines lives in the import library beside it, and the DLL is what the loader picks up afterwards by the name recorded in the import.

getCompilerRTImportLibraryPath already existed and ObjectCompiler already used it. This was the one place left that named the DLL.

The error for a missing file now says which file, since "unable to locate Mojo CompilerRT library" with no path was not much help when the problem was that it was looking for the wrong one.

Verified by cross building a Windows mojo.exe, staging it with an lld-link.exe next to it and the runtime under lib/, and building a hello world on a Windows host:

C:\tmp\bld1> mojo build hello.mojo
BUILD_RC=0
C:\tmp\bld1> hello.exe
hello from a windows build
RUN_RC=0

That is the first Mojo program compiled to an executable on Windows by a Windows compiler. Before this change the same command got as far as the linker and no further.

The built binary imports KERNEL32.dll and KGENCompilerRTShared.dll and nothing else, and the runtime DLL has to be beside it to start, which is the packaging question in #319 rather than anything here.