Refresh a few Android SDK components

[grendello]

Most updates are small increases in version numbers, with the exception of
android_m2repository which leaps forward 31 releases. This commit brings us to
the current versions as distributed upstream.

[grendello]

platform 28 update breaks our build:

[2019-06-13T14:20:03.735Z]   obj/Release/android-28/mcw/Java.Lang.StringBuffer.cs(259,32): error CS0111: Type 'StringBuffer' already defines a member called 'Append' with the same parameter types [/Users/builder/jenkins/workspace/xamarin-android-pr-pipeline-release/xamarin-android/src/Mono.Android/Mono.Android.csproj]
[2019-06-13T14:20:03.735Z]   obj/Release/android-28/mcw/Java.Lang.StringBuilder.cs(259,32): error CS0111: Type 'StringBuilder' already defines a member called 'Append' with the same parameter types [/Users/builder/jenkins/workspace/xamarin-android-pr-pipeline-release/xamarin-android/src/Mono.Android/Mono.Android.csproj]

This might be because of either this or this implicit conversion operator, however it looks more like an issue with the generator?

[lambdageek]

@grendello Do we need a corresponding bump in Mono https://github.com/mono/mono/blob/377030eaab594540d7e043f8657a30bbe92e6c33/sdks/versions.mk#L12-L24 ?

[jonpryor]

@lambdageek: It wouldn't hurt?

Unrelated: PR #3219 excludes the MonoTests.Mono.Unix.Native.SocketTest.Accept4 test because Mono_Posix_Syscall_accept4 doesn't exist in libMonoPosixHelper.so. However, that used to work, presumably because (at some point?) libMonoPosixHelper.so was built to target (support targeting?) API-21+. Since it's currently targeting API-16, it doesn't find accept4(), hence the test failure.

Should this be addressed somehow? Or should someone dig into what happened in this commit range to cause the Accept4() unit test to fail? mono/mono@e113ce9...c6edaa6

[jonpryor]

Commit message for merge:

Update the versions of various Android SDK components:

  * Bump Android emulator package to 29.0.11.
  * Use SDK Tools 29.* instead of 28.*.
  * Use `android_m2repository` r47 instead of r16 (?!)
  * Update Android SDK package revisions used, except for API-28.

Include additional files in the `xa-build-status*.zip` and
`xa-test-results*.zip` files.

Improve Android SDK package version checking so that when a package
is updated (e.g. `pkgRevision` change), the package is updated.
(This is why `pkgRevision` is now tracked separately.)

On "interesting" SNAFU happened in the lifetime of this commit: it
originally included a bump to API-28 r5 (`platform-28_r05.zip`),
which [subsequently broke `Mono.Android.dll` compilation][0]:

	src\Mono.Android\obj\Release\android-28\mcw\Java.Lang.StringBuffer.cs(259,32): Error CS0111: Type 'StringBuffer' already defines a member called 'Append' with the same parameter types

The immediate cause of this error is that API-28 *removed* the
`package`-private type `java.lang.AbstractStringBuilder`, which broke
our binding (and is something we need to separately address):

	# From platform-28_r04.zip (currently used):
	$ jar tf ~/android-toolchain/sdk/platforms/android-28/android.jar | grep AbstractSt
	java/lang/AbstractStringBuilder.class

	# From platform-28_r06.zip:
	$ jar tf android.jar | grep AbstractStr
	# no matches

However, there were unanticipated ramifications: because previous
versions of `xaprepare` didn't know about package revisions, they
didn't "downgrade" the Android SDK installed on the machine.
Consequently, *other PRs* would fail with the same CS0111 error
because they were on a machine with API-28 r06 installed.
(Which is why it's paramount we get a version of this commit in
sooner rather than later, so that we can "un-botch" our build bots.)

Finally, [address][1] the rando [`EmbeddedDSOUnitTests` failures][2],
which are caused because the `x86_64` arch files aren't consistently
installed.  This in turn happens because `make prepare jenkins` is
unreliable, because `make jenkins` requires
`bin/Build$(Configuration)/rules.mk`, which is created by
`make prepare`.  There is thus an ordering problem: `make jenkins`
must happen *after* `make prepare` has *completed* so that it can
properly import `rules.mk`.  The fix is to execute `make jenkins`
separately from `make prepare`.

[0]: https://devdiv.visualstudio.com/DevDiv/_build/results?buildId=2767236&view=logs&jobId=cac0e8d3-0ef5-5d2b-b57e-e8fde7204df3
[1]: https://xamarinhq.slack.com/archives/C03CEGRUW/p1560518047300700
[2]: https://jenkins.mono-project.com/job/xamarin-android-pr-pipeline-release/1299/testReport/