Fix mingw build fail caused by c57f8a4

c57f8a4 changes to `src/ninja.cc` break the mingw builds due to incorrect macro usage. MinGW based toolchains define `_WIN32` and `WIN32` so `_MSC_VER` should be used to determine if building with VC's `cl` and friends.

FYI, if you're doing Windows patches and need an easy, all-in-one MinGW toolchain to test with, I maintain a few different flavors of "DevKit's" at [TheCodeShop download page](https://github.com/thecodeshop/ruby/wiki/Downloads)

<pre><code>
C:\Users\Jon\Documents\CDev\ninja-git>git log -3 --oneline
d95fcb0 Merge pull request #416 from nico/slide
a79de82 Merge pull request #415 from nico/getopt
48143c9 Change rate measurement code.

C:\Users\Jon\Documents\CDev\ninja-git>ninja
[19/20] AR build\libninja.a
        1 file(s) moved.
[20/20] LINK ninja.exe
FAILED: g++ -Lbuild -static -o ninja.exe build\ninja.o -lninja
build\ninja.o: In function `ToolMSVC':
C:\Users\Jon\Documents\CDev\ninja-git/src/ninja.cc:301: undefined reference to `MSVCHelperMain(int, char**)'
collect2.exe: error: ld returned 1 exit status
ninja: build stopped: subcommand failed.
</code></pre>

This occurs because the `build.ninja` rule for `libninja.a` (correctly) doesn't include the VC needed parts.

<pre><code>
// build.ninja generated from `python configure.py --platform=mingw`
...
build $builddir\libninja.a: ar $builddir\build.o $builddir\build_log.o $
    $builddir\clean.o $builddir\depfile_parser.o $builddir\disk_interface.o $
    $builddir\edit_distance.o $builddir\eval_env.o $builddir\explain.o $
    $builddir\graph.o $builddir\graphviz.o $builddir\lexer.o $
    $builddir\manifest_parser.o $builddir\metrics.o $builddir\state.o $
    $builddir\util.o $builddir\subprocess-win32.o $builddir\getopt.o

# Main executable is library plus main() function.
build $builddir\ninja.o: cxx src\ninja.cc
build ninja: phony ninja.exe
build ninja.exe: link $builddir\ninja.o | $builddir\libninja.a
  libs = -lninja
</code></pre>

This patch works for me using both mingw-based GCC 4.7.1 and WinSDK 7.1 toolchains on my Win7 32bit system. Below is the output from building using WinSDK 7.1 cmd line tools:

<pre><code>
C:\Users\Jon\Documents\CDev\ninja-git>cl /?
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 16.00.30319.01 for 80x86

# dammit, only VC IDE sets `VCINSTALLDIR`...hack it so `bootstrap.py` works for WinSDK 7.1
C:\Users\Jon\Documents\CDev\ninja-git>set VCINSTALLDIR=C:\Program Files\Microsoft Visual Studio 10.0\VC\

C:\Users\Jon\Documents\CDev\ninja-git>python bootstrap.py
Building ninja manually...
build.cc
build_log.cc
clean.cc
depfile_parser.cc
disk_interface.cc
edit_distance.cc
eval_env.cc
explain.cc
graph.cc
graphviz.cc
includes_normalize-win32.cc
lexer.cc
manifest_parser.cc
metrics.cc
minidump-win32.cc
msvc_helper-win32.cc
msvc_helper_main-win32.cc
ninja.cc
state.cc
subprocess-win32.cc
Generating Code...
Compiling...
util.cc
Generating Code...
Compiling...
getopt.c
Generating Code...
Building ninja using itself...
warning: A compatible version of re2c (>= 0.11.3) was not found; changes to src/*.in.cc wi
ll not affect your build.
wrote build.ninja.
[24/24] LINK ninja.exe
Generating code
Finished generating code

Done!

Note: to work around Windows file locking, where you can't rebuild an
in-use binary, to run ninja after making any changes to build ninja itself
you should run ninja.bootstrap instead.  Your build is also configured to
use ninja.bootstrap.exe as the MSVC helper; see the --with-ninja flag of
the --help output of configure.py.
</code></pre>