buildenv/win32-static, gyp: update win32-static buildenv to use explicit /arch:IA32 on MSVS2012+.

Visual Studio 2012 and greater generates SSE2 code (equivalent
to /arch:SSE2) when no /arch parameter is passed to cl.exe.

We're not interested in that for Mumble, which historically has
only required SSE.

This commit changes the win32-static build environment
to build all libraries with /arch:IA32 in order to
keep backwards compatibility.

We could have chosen to go directly for /arch:SSE, but
/ARCH:IA32 matches the behavior of VS2010 (and earlier),
so that's what we're going for in this first pass. We might
want to re-evaluate that in the future, now that a lot of
infrastructure for setting the /arch flag for all our dependencies
is in place.

How is this implemented?

There are basically two parts to this change.

The first part is a change to common.bash to add /arch:IA32
to the "CL" environment variable when building with VS2012
(or greater). This ensures that all command-line builds pass
that parameter when invoking cl.exe. However, it's worth noting
that this won't be visible when inspecting the actual command line
of cl.exe invocations, since the flags passed via the "CL"
environment variable are all applied internally.

The second part is a set of changes to various .vcxproj files
for our libraries. Any build script that does a MSBuild-style
build of a .vcxproj/.sln now modifies its .vcxproj files when
building under VS2012 (or greater) to ensure that /arch:IA32 is
passed to the compiler. This happens using a compiler property
called EnableEnhancedInstructionSet, which we set to NoExtensions
to force /arch:IA32 to be passed.

Strictly speaking, the CL environment variable trick from the
first part should also affect MSBuild-style builds, but there
is still value in having the build settings be explicitly spelled
out in the .vcxproj files.

In the future, we might want the build scripts to specify whether
they're a command-line-style build or an MSBuild-style build. Then
we would only set the CL environment variable for pure CLI-style
builds, and use the explicitly .vcxprojs for MSBuild-style builds.

We have a similar issue with VS2012+'s XP compatibility mode, which
also sets the CL environment variable (among other things) for
CLI-style builds. MSBuild-style builds, however, pass the
/p:PlatformToolset=v120_xp parameter to MSBuild.exe to tell the build
to output XP-compatible code. In this case, the MSBuild-style build is
also (needlessly) affected by the CL (and other) environment variables,
even though passing /p:PlatformToolset=v120_xp should be enough.