Link dynamically with GC on Windows. Closes #669.

This issue is manyfold.

First off, we're building our own vendored boehm-gc, and we were only copying
the static libraries by hand (ugly solution, but it works). On Windows, we're
copying 'libgc.dll.a' as well now, along with 'libgc-1.dll' to 'ROCK_DIST/bin'.
Why put it there?  Because now the dll is needed when executing all
rock-compiled programs on Windows, and since 'ROCK_DIST/bin' should be in the
PATH at least on systems where rock is installed, this is good in a dev
environment. For production, bundling libgc-1.dll will be documented.

Then, CommandLine now sets dynGC to true by default on Windows so that it links
dynamically when nothing is specified. Similarly, in the make driver, detecting
a Windows OS sets DYN_GC to true. The corresponding library paths were added
both in Flags and in the make driver. Also, the --gc option no longer
influences the resulting Makefile at all.

But wait, there's more! There's also a matter of -lpthread vs -pthread vs the
world.  I've arrived at the following conclusions. On Windows, we don't use
pthreads at all, and we assume the GC was built supporting Win32 threads (what
the SDK is built upon), so it makes no sense to link with pthreads at all, even
if it's available (mingw-get installs pthreadsw32 by default now, afaict).
Everywhere else, -lpthread has been working by luck but -pthread should be used
instead, because it might add -D_REENTRANT and also there might not be a pthread
library at all on some systems (e.g. in might be built-in). However, on Windows,
MinGW32 requires the -mthreads (with an s) command line option to "turn on some
multithreaded support in Windows headers and also link with -lmingwthrd" which
apparently does some cleanup. Regardless, on Windows we now build with -mthreads,
and everywhere else, with -pthread.