[Xamarin.Android.Build.Tasks] locate $(JdkJvmPath) only when needed

[jonathanpeppers]

Fixes: #2409
Context: https://github.com/xamarin/xamarin-android/wiki/Build-Performance-Results

When doing the latest performance comparison, I noticed the
<ResolveSdks/> MSBuild task is a bit slower:

* VS 15.9
 80 ms  ResolveSdks                                7 calls
* VS 16.0 p2 (master)
127 ms  ResolveSdks                                7 calls

For $(AndroidGenerateJniMarshalMethods) support, we needed to locate
a new $(JdkJvmPath) location.

Since <ResolveSdks/> finds $(JdkJvmPath) on first build, and
design-time builds, it is worth making sure this task doesn't get any
slower. The initial design-time build happens on "solution create",
which is one of the more important metrics the VS team measures.

So I split out the logic finding $(JdkJvmPath) and put it in a new
<ResolveJdkJvmPath/> MSBuild task.

Also setup a Condition, so it only runs if:

• Not a $(DesignTimeBuild)
• $(AndroidGenerateJniMarshalMethods) is enabled
• $(JdkJvmPath) is blank

This should save ~50ms on DTBs and first builds.

[radekdoulik]

Let ask @jonpryor about that, as we already had the separate task once #2153 (review) and he suggested to do it in ResolveSdks instead.

Now the circumstances changed (the DTB performance is important), but I guess we can still keep it in ResolveSdks and add ResolveJvmPath bool parameter to specify, whether the task should also resolve the JvmPath? That parameter value would be: '$(AndroidGenerateJniMarshalMethods)' == 'True'

I am OK with both alternatives, just don't remember what was the reasoning for not having it in separate task.

[jonpryor]

My original concern was around consistency of the JVM path which was used:

This way we ensure that we're consistent. By using JdkInfo.GetKnownSystemJdkInfos(), it's possible that <ResolveSdks/> will provide one JDK path, but JdkJvmPath could come from a different path.

I believe that in the original incarnation of the <JdkInfo/> task added in PR #2153, <JdkInfo/> didn't accept an "input" Java SDK Path property, but simply re- computed the JVM path based on Xamarin.Android.Tools.JdkInfo, which might not find the same path <ResolveSdks/> would have come up with (in part because <ResolveSdks/> reads $(JavaSdkDirectory), which could be overridden to point to ~anywhere).

Keeping both the JavaSdkPath and JdkJvmPath logic within <ResolveSdks/> thus helped ensur a degree of consistency.

The approach here does afford consistency between the <ResolveJdkJvmPath/> and <ResolveSdks/> tasks, because of the ResolveJdkJvmPath.JavaSdkPath property, and the only way they could differ is if the path that <ResolveSdks/> computes is an "invalid" path as far as Xamarin.Android.Tools.JdkInfo is concerned, but that was already a possibility when it was within <ResolveSdks/>, because ResolveSdks.JavaSdkPath wasn't updated if new JdkInfo(JavaSdkPath) ever threw.