[Java.Interop] $(Version) depends on TargetFramework

[jonpryor]

Context: 2d5431f
Context: 88d6093
Context: #936
Context: https://github.com/jonpryor/java.interop/commits/jonp-registration-scope

Versioning is hard.

Way back in 3e6a623 we tried to use the GitInfo NuGet package so
that all assemblies would have a version number which contained the
number of commits since GitInfo.txt changed.

This turned out to have unanticipated breakage, and was largely
reverted in 2d5431f for "core" libs like Java.Interop.dll.

This still presents a problem, though: the point to assembly
versioning is to prevent accidental breaking of referencing
assemblies. If we add a new member to Java.Interop.dll but
fail to update the version, then that permits a scenario in which
an app/lib depends on the new member, but is built against a version
missing that member. This results in runtime exceptions.

The whole reason this hasn't been a problem so far is because
Java.Interop.dll has barely changed in years. (Plus, most usage
is hidden behind other layers and libs…)

However, I want this to change: #936 and
jonpryor/java.interop/jonp-registration-scope both add new public
API to Java.Interop.dll, and there are other features and
optimizations we're considering that would also require API changes.
A policy of "no changes" isn't tenable.

Thus: allow Java.Interop.dll built for .NET 6 to have a different
$(Version) than the one built for .NET Standard 2.0.

Fixing this was unexpectedly problematic, as commit 88d6093:

Update[d] Java.Interop.BootstrapTasks.csproj to no longer
<Import/> VersionInfo.targets, as this causes a circular
dependency (VersionInfo.targets uses tasks from
Java.Interop.BootstrapTasks.dll). This is fine, as
Java.Interop.BootstrapTasks.dll doesn't need to be versioned.

Java.Interop.BootstrapTasks.dll doesn't need to be versioned, but
other libraries do, and this change change meant that
VersionInfo.targets was never used, which in turn meant that e.g.
bin/BuildDebug/Version.props was never created.

Re-introduce VersionInfo.targets by "moving" it into
build-tools/VersionInfo/VersionInfo.csproj, and adding
VersionInfo.csproj to Java.Interop.BootstrapTasks.sln.
This allows the Prepare target to create
bin/Build$(Configuration)/Version.props.

This in turn requires moving Java.Interop.BootstrapTasks.sln into
topdir, so that it can use global.json and the
Microsoft.Build.NoTargets version entry.

Next, update Java.Interop.csproj so that $(Version) is
conditional on $(TargetFramework). This allows it to continue
using version 0.1.0.0 for .NET Standard 2.0, and begin using
6.0.200.* for .NET 6+ builds.

Update the default $(Version) value to be 6.0.200.* instead of
0.1.*.0, matching the .NET SDK for Android workload version.

Finally -- and most of the "noise" in this commit -- "cleanup and
unify" the disparate build systems. The above $(Version) changes
necessitate updating the make prepare rule & msbuild /t:Prepare
target.

Clean this up: the dotnet-based MSBuild environment is now our
Source Of Truth, and the make targets are updated to rely on the
Prepare target instead of duplicating most of the logic.

Update msbuild.mk so that dotnet build is used instead of
msbuild.

While cleaning up Makefile, remove other cruft such as the explicit
gcc calls to build the NativeTiming lib (we have a .csproj as
of 5c756b1; use it!), and rationalize
Java.Runtime.Environment.dll.config generation.

Rename the <GenerateVersionFile/> task to <ReplaceFileContents/>,
as that better describes what this task actually does.

Rename the JdkInfo.JdksRoot property to JdkInfo.JdkRoot, as this
better conveys actual semantics, and -- as part of "makefile cleanup"
-- stop probing for /System/Library/JavaVirtualMachines on macOS,
which removes a warning from make prepare:

warning : Could not get information about JdksRoot path `/Library/Java/JavaVirtualMachines`:
Could not find required file `jar` within `/Library/Java/JavaVirtualMachines`; is this a valid JDK?

(No, not is is not a valid JDK. It never was, and I now have to
believe that this has always warned.)

[jonathanpeppers]

This looks right: https://github.com/dotnet/sdk/blob/2a515cdbd8f6be1b019ae2c8d7f21952592f0697/src/Tasks/Microsoft.NET.Build.Tasks/targets/Microsoft.NET.GenerateAssemblyInfo.targets#L205-L214

We might want to manually check the Java.Interop.dll in the next java.interop bump? Will we remember?

[jpobst]

This allows it to continue using version 0.1.0.0 for .NET Standard 2.0, and begin using 6.0.200.* for .NET 6+ builds.

I do not believe we can allow the Java.Interop.dll version to "float" like this.

Imagine I install .NET 6.0.300.0, build my binding library with it, and publish the NuGet. All binding libraries take an assembly reference on Java.Interop.dll, so my library will require Java.Interop.dll 6.0.300.0.

However, the only versioning that NuGet is aware of is net6.0-android31.0, meaning any project targeting that can add a package reference to my NuGet and expect it to work.

If someone is still using .NET 6.0.200.0, NuGet will allow them to reference the binding package, but their compilation will always fail with the same error we had to back out in 2d5431f.

error CS1705: Assembly 'Microsoft.Maui' with identity 'Microsoft.Maui, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null'
uses 'Java.Interop, Version=6.0.300.0, Culture=neutral, PublicKeyToken=84e04ff9cfb79065'
which has a higher version than referenced assembly
'Java.Interop' with identity 'Java.Interop, Version=6.0.200.0, Culture=neutral, PublicKeyToken=84e04ff9cfb79065'

We can hardcode Java.Interop.dll to <Version>6.0.0.0</Version> if we want to, because that is the same "contract" as "net6.0". But we cannot change the version (or api) in minor or patch versions of NET 6. The next available version would be 7.0.0.0.

[jonpryor]

Superseded by PR#952.