Changes in xamarin-android-tools between 75530565b6aa903b3a0e52b61df4dd94475a19fc and 9e78d6ee586b498d0ea082b3bc00432c23583dd1:

9e78d6e (HEAD, origin/master, origin/HEAD, master) [tests] fix test failures on Windows (#47)
bdf0158 Better support no installed JDKs on macOS (#48)
6353659 Log what is happening during path selection (#46)
3ef860b Take BUILD_NUMBER into consideration for Version sorting (#45)
d3de054 Allow an optional locator to be provided to JdkInfo (#43)
917d3b3 Don't require quotes around `release` values (#41)
7427692 [tests] Unit tests for finding NDK location based on $PATH (#40)
dbc517b Merge pull request #38 from jonpryor/jonp-ndk-via-path
511d580 Allow finding NDK location based on $PATH
b42c217 [tests] Fix DetectAndSetPreferredJavaSdkPathToLatest() test (#37)
a4aad18 Add AndroidSdkInfo.DetectAndSetPreferredJavaSdkPathToLatest() (#35)
fae7e0a [tests] Remove temporary directories (#36)
07c4c2b [Xamarin.Android.Tools.AndroidSdk] Revert JDK validation (#34)

Context: http://work.devdiv.io/667174
Context: dotnet/android#2105
Context: 893562c

Turns Out™ that resolving PCL assemblies within Xamarin.Android is
not as fast as resolving `MonoAndroid`-profile assemblies; see commit
893562c, wherein we see that non-PCL use is 30-50% faster than PCL
assembly use -- shaving off ~4 seconds -- for unknown reasons.

Run with it: allow `Java.Interop.dll` to be built as a
`MonoAndroid,v1.0`-profile assembly in addition to a PCL.
To do this we need to allow `$(TargetFrameworkVersion)` to be
overridden "elsewhere" -- specifically in `Mono.Android.targets`
within the xamarin-android repo -- otherwise `Java.Interop.dll`
will be built for the *wrong* framework profile.