Context: dotnet/android-tools#85
Context: dotnet#4567

Partially reverts commit 5ad666d.

Commit 5ad666d bumped the Android SDK Build-tools version that
`xaprepare` installs to be 30.0.0-rc4, which is problematic becuase it
contains an `apksigner.jar` which requires JDK11, support for which
has not yet been merged (see PR dotnet#4567).

In retrospect, bumping the `$(XABuildToolsVersion)` value was a
Bad Idea™.  It was the `DexUtils.cs` change that we wanted.

Revert the `$(XABuildToolsVersion)` bump, and thus once again provision
Android SDK Build-tools 29.0.2.

Context: dotnet/android-tools#85
Context: #4567

Partially reverts commit 5ad666d.

Commit 5ad666d bumped the Android SDK Build-tools version that
`xaprepare` installs to be 30.0.0-rc4, which is problematic becuase it
contains an `apksigner.jar` which requires JDK11, support for which
has not yet been merged (see PR #4567).

In retrospect, bumping the `$(XABuildToolsVersion)` value was a
Bad Idea™.  It was the `DexUtils.cs` change that we wanted.

Revert the `$(XABuildToolsVersion)` bump, and thus once again provision
Android SDK Build-tools 29.0.2.

Context: dotnet/android-tools#85
Context: #4567

Partially reverts commit 5ad666d.

Commit 5ad666d bumped the Android SDK Build-tools version that
`xaprepare` installs to be 30.0.0-rc4, which is problematic becuase it
contains an `apksigner.jar` which requires JDK11, support for which
has not yet been merged (see PR #4567).

In retrospect, bumping the `$(XABuildToolsVersion)` value was a
Bad Idea™.  It was the `DexUtils.cs` change that we wanted.

Revert the `$(XABuildToolsVersion)` bump, and thus once again provision
Android SDK Build-tools 29.0.2.

Context: dotnet/android#4735 >
         https://devdiv.visualstudio.com/DevDiv/_build/results?buildId=3771781&view=ms.vss-test-web.build-test-results-tab&runId=13535824&resultId=100072&paneView=attachments
Context: dotnet/android#4567
Context: https://github.com/xamarin/androidtools/commit/a3965baeea566ba6a1f346c676d9e2d5ecba6167

The Windows Smoke Tests are failing on PR #4735, because the wrong
Android SDK Build-tools version is being used:

	Task "ResolveAndroidTooling" (TaskId:9)
	  Task Parameter:AndroidSdkBuildToolsVersion=29.0.2 (TaskId:9)
	  …
	  Trying build-tools path: C:\Users\dlab14\android-toolchain\sdk\build-tools\30.0.0-rc4 (TaskId:9)
	  …
	  ResolveAndroidTooling Outputs: (TaskId:9)
	    AndroidSdkBuildToolsPath: C:\Users\dlab14\android-toolchain\sdk\build-tools\30.0.0-rc4 (TaskId:9)

Here, Build-tools 30.0.0-rc4 is used.

Why is that a problem?  Because JDK 1.8 is still used!

	C:\Program Files\Android\jdk\microsoft_dist_openjdk_1.8.0.25\bin\java.exe -jar C:\Users\dlab14\android-toolchain\sdk\build-tools\30.0.0-rc4\lib\apksigner.jar sign --ks "C:\Users\dlab14\AppData\Local\Xamarin\Mono for Android\debug.keystore" --ks-pass pass:android --ks-key-alias androiddebugkey --key-pass pass:android --min-sdk-version 21 --max-sdk-version 29 …
	java.lang.UnsupportedClassVersionError: com/android/apksigner/ApkSignerTool has been compiled by a more recent version of the Java Runtime (class file version 53.0), this version of the Java Runtime only recognizes class file versions up to 52.0

JDK11 is required in order to use Build-tools r30+, but we don't
currently support JDK11 use; see PR #4567.

What's happening is that *because of* PR #4567, some of the build
machines are being provisioned with Build-tools 30.0.0-rc4, i.e. e.g.
`$HOME/android-toolchain/sdk/build-tools/30.0.0-rc4` *exists*.
*Because* that directory exists -- and *isn't* parse-able by
`System.Version.TryParse()` -- it's considered to be a "preview"
version, and thus *has priority over non-preview versions*, and thus
is returned *first*.  *Because* it's returned *first*,
`<ResolveAndroidTooling/>` prefers it, causing the
`<AndroidApkSigner/>` task to subsequently fail, because it's
unusable.

The "workaround" is for `$(AndroidSdkBuildToolsVersion)` to be set to
the desired version to use.

In retrospect, however, this is all *backwards*:
`AndroidSdkInfo.GetBuildToolsPaths()` shouldn't prefer preview
versions, it should prefer *non-* preview versions.  If you *really*
want a preview version, *then* you should override
`$(AndroidSdkBuildToolsPath)`.

Previews should be opt-in, not opt-out.

With that in mind, why were preview versions preferred in the first
place?  That was done in xamarin/androidtools@a3965bae to fix
[Bug #30555][0], stating:

> handle[] by searching for these "preview" directories first, so that
> the latest tooling will be used IF the user decides to install it.
> The assumption is that a stable release will NOT inlcude a suffix.

While "a preview directory will only exist if someone explicitly
installs it, and thus should be preferred" sounds reasonable, in
retrospect it's a recipe for pain when using a shared CI environment.
Just because it's there does *not* mean it should be used.

[0]: https://bugzilla.xamarin.com/show_bug.cgi?id=30555