[xa-prep-tasks] Use the Mono bundle

[jonpryor]

DO NOT MERGE

Before merging the bundle filename needs to be changed (see the TODO in the commit). I don't want to do this yet so that I can see if the current bundle is used by the PR bot. :-)

---

Context: fbfd676

Stage 3 of the cunning plan is to (attempt to) use the mono bundle
introduced in commit fbfd676.

This "simple" desire (ha!) re-raises the architectural project
dependency issue "solved" in fbfd676, but first, a simple question:

What should download the mono bundle?

There are two plausible answers:

1. make prepare can (somehow) handle it.
2. MSBuild can (somehow) handle it.

Both are plausible. The problem with using make targets (1) is there
is increased potential for "duplication" -- duplication of the bundle
filename, downloading it, and extracting it. Plus, make isn't
"Windows friendly", in that GNU make isn't (normally) present with
Visual Studio. (NMAKE is, but the Makefiles in this project are not
compatible with NMAKE.)

Which brings us to MSBuild (2): can it handle the task?

To tackle that, we need to be able to have an MSBuild task project
which has no dependencies, so that it can download and extract the
mono bundle before anything else runs, as it may be downloading
contents which mean that other projects don't need to run.

The need for a "pre-bootstrap" task assembly -- called xa-prep-tasks
-- thus "undoes" some of the logic regarding libzip-windows.mdproj
and the <Zip/> task from fbfd676: it isn't possible to rely on
libzip from a "pre-build" state, as libzip is one of the things in
the mono bundle, so now we need two "bootstrap" task assemblies:
one without a libzip dependency -- xa-prep-tasks.dll -- and one
with a libzip dependency --
Xamarin.Android.Tools.BootstrapTasks.dll

Move tasks which don't currently require libzip -- or won't in the
future, or laziness -- from Xamarin.Android.Tools.BootstrapTasks.dll
and move them into xa-prep-tasks.dll.

With that architectural compromise in place, add xa-prep-tasks as a
@(ProjectReference) to various projects to help ensure it's built
first, and rearchitect bundle.mdproj so that
xa-prep-tasks.targets and bundle.targets can use the same targets
to compute the bundle filename, now in
build-tools/bundle/bundle-path.targets.

Add a post-build step to xa-prep-tasks.csproj which downloads and
extracts the expected mono bundle.

One "problem" (feature?) is that the new <SystemUnzip/> task doesn't
report errors as errors when unzip'ing the file. This turns out to be
fine here because when downloading the mono bundle from Azure we don't
get a 404 anyway -- Azure instead returns an XML document containing
an error message (wat?!). We can thus ignore most error handling
entirely...though we're also ignoring any checking for invalid
downloads, which is something we should address in the future.

Update the varioous project files so that they won't attempt to
rebuild binaries that were present in the mono bundle.

Finally, the mono bundle isn't quite right, as it installs llc.exe
and opt.exe into bin/, not lib/mandroid. This was overlooked in
commit fbfd676.

Add a version number to the bundle filename so that a unique filename
is used, thus ensuring that we attempt to download an updated mono
bundle in the future, and correct the CreateBundle target so that it
packages required files.

[jonpryor]

1. This PR builds!
2. This PR takes ~1/3 the time, taking ~4.5 minutes to build, compared to the historical average of 12 minutes.

[grendello]

I'm not a fan of this kind of {x,ms}build invocation, to be honest. It's convenient if it works, but if it breaks... The error output of msbuild is mangled and next to impossible to read, also it gets interpreted by shell as a set of commands. Maybe (not as part of this PR) we should have a wrapper script for such one-liners that will properly check the exit status of the command as well as log and process its output.

[grendello]

LGTM

[radical]

Should the v2 be a property? It is being used in more than one place and sounds like something that might be updated in future too.

[jonpryor]

Where else is -v2 being used? It should only be used in this property.

[radical]

https://github.com/xamarin/xamarin-android/blob/master/build-tools/bundle/bundle.targets#L36

[radical]

Other than what I commented on, LGTM!