[mxe] Add Windows cross-compiler support.

[jonpryor]

Certain Xamarin.Android features require that Mono be built for
Windows, e.g. the AOT compilers require a build of mono that
executes on Windows to generate the AOT native libraries.

Unfortunately, building Mono on Windows continues to be a massive
PITA. (Autotools on Windows requires Cygwin/mingw, running shell
scripts on Windows is painfully slow, it's all brittle, etc.)

To work around this pain, we instead build the Mono/Windows binaries
on OS X, via MXE, which produces a gcc-based cross-compiler
which generates Windows binaries and is executable from Unix.
This in turn requires that we have MXE, so add a
_CreateMxeToolchains target to android-toolchain.targets which
will build MXE. The installation prefix for MXE can be overridden via
the new $(AndroidMxeInstallPrefix) MSBuild property; it defaults to
$HOME/android-toolchain/mxe.

Rework the $(AndroidSupportedAbis) MSBuild property so that it
must include the "host" ABI, and add support for a new host-win64
value which will use MXE to generate 64-bit Windows binaries for
libmonosgen-2.0.dll and libMonoPosixHelper.dll.

We can't always process host-$(HostOS) because of an xbuild bug.
The scenario is that if you want to just build host-win64, the
obvious thing to do is:

cd build-tools/mono-runtimes
xbuild /p:AndroidSupportedAbis=host-win64

Alas, if host-$(HostOS) is always processed, this inexplicably
causes host-$(HostOS) to be re-rebuilt, which (1) is a waste of
time, and (2) fails -- inexplicably -- in the _BuildRuntimes target
because make(1) thinks that the configure flags have somehow changed,
which currently makes no sense at all. (When can we move to MSBuild?)

Changing $(AndroidSupportedAbis) so that host-$(HostOS) is
explicitly processed instead of implicitly processed allows working
around the above xbuild bug, as host-$(HostOS) won't be implicitly
processed on every build, but only when required.

Additionally, we add a new MSBuild task so that we can
determine of a particular process is in $PATH. This is useful
becuase listing requirements within README.md is a road to pain --
e.g. xxd(1) is required to build src/monodroid but if it's missing
it'll still build but you'll instead get a linker failure because
the monodroid_config and monodroid_machine_config symbols aren't
present. Building MXE requires that even more programs be present
within $PATH, so explicitly check for these so that useful error
messages can be generated instead of obscure ones.

Finally, a note about autotools and generating Windows native
libraries: creation of .dll files requires that an appropriate
objdump be present so it can determine if e.g. libkernel32.a is an
import library or an archive. If x86_64-w64-mingw32.static-objdump
isn't found -- e.g. because $PATH doesn't contain it -- then no .dll
files will be created, and much head scratching will occur.

To rectify this, override the OBJDUMP and DLLTOOL values when invoking
configure so that that full paths are used and $PATH use is
reduced. (Who wants x86_64-w64-mingw32.static-objdump in $PATH?)

[radical]

Should the separator here be a , instead of a ; ?

[grendello]

I'd suggest setting the default compiler names to HostCc = cc and HostCxx = c++ which on OSX are symlinked to clang and clang++, respectively, and on Linux they point to g++ and gcc. This makes the setting more "portable" since clang isn't installed by default by most Linux distributions yet.

[jonpryor]

that can be done as a separate commit.