[Xamarin.Android.Tools.AndroidSdk] Probe for Zulu JDK

[jonpryor]

Context: https://www.azul.com/downloads/zulu-community/

Commit 237642c removed support for the ancient
microsoft_dist_openjdk_* versions, replacing it with the newer
Microsoft OpenJDK.

One problem with this change is one of compatibility:
microsoft_dist_openjdk_ was a build of JDK 1.8, while
Microsoft OpenJDK only provides builds for JDK 11 and later.
This is a problem, as the Visual Studio Android Designer
currently requires JDK 1.8, and is not yet compatible with JDK 11.

Add support to probe for for Azul Zulu OpenJDK installation
directories, as Zulu provides updated JDK 1.8 installers.

Additionally, refactor and centralize the JDK Location logic.
Previously, JdkInfo.GetKnownSystemJdkInfos() would return all of
the Windows installation locations before the macOS/Linux/etc.
locations, which made it possible for Windows and non-Windows
platforms to return paths in an inconsistent order. Introduce a new
JdkLocations helper, and add new subclasses for each specific JDK
location, so that JdkInfo.GetKnownSystemJdkInfos() can be unified
across macOS/Linux & Windows, increasing consistency.

Add a new tools/ls-jdks tool, to make it easier to print all probed
JDK locations.

[jonpryor]

TODO: write a better commit message. (It's a draft!)

"Primary" motivation is to add support for the Azul Zulu JDK.

"Secondary" motivation -- which is most of the diff, by far -- is to bring a degree of sanity here. Previously, JdkInfo.GetKnownSystemJdkInfos() was spread across Windows support, localized within AndroidSdkWindows, and non-Windows (macOS, Linux) support, within JdkInfo itself.

For me, at least, this makes understanding the lookups "weird".

Unify these systems, creating 6 "JDK Location" classes which know where to look for one and only one "JDK", for both macOS & Windows, and use these unified "finders" within JdkInfo.GetKnownSystemJdkInfos().

I find this a tad "cleaner".

Keep in mind that we'll be wanting to add Yet Another JDK location next week, for Adopt OpenJDK, so I find making things "more understandable" to be a benefit.

[grendello]

LGTM, but I wonder if we should have a class that also looks in ~/android-toolchain/jdk without having to put that location in JAVA_HOME? I know it would work only on systems where one builds Xamarin.Android, but it should be harmless on other machines while making it easier to use XA JDK as the main one on developer's machine.

[jonathanpeppers]

Comment is outdated