[Java.Interop] allow $(TargetFrameworkVersion) to be passed in

[jonathanpeppers]

Context: dotnet/android#2105 (comment)

To build Java.Interop.csproj as MonoAndroid,v1.0, we need to set
the following properties:

<PropertyGroup>
    <TargetFrameworkIdentifier>MonoAndroid</TargetFrameworkIdentifier>
    <TargetFrameworkVersion>v1.0</TargetFrameworkVersion>
    <TargetFrameworkRootPath>$(XAInstallPrefix)xbuild-frameworks</TargetFrameworkRootPath>
</PropertyGroup>

Currently it looks like $(TargetFrameworkVersion) is the only one we
can't modify downstream in xamarin-android.

[jonpryor]

I'm torn here. :-(

On the one hand, I've long wanted to turn Mono.Android.dll into a PCL/.NETStandard library -- assuming that was possible, I haven't yet tried -- because:

1. It's the future!!!!oneone!!!!eleventy!!!
2. monodis Mono.Android.dll would actuall work.

(Never mind that monodis has been "replaced" with ikdasm; ikdasm is slow. monodis kinda/sorta works, if you override $MONO_PATH, but that's often flakey and fails at the drop of a hat due to mono/mscorlib mismatches.)

This PR moves us away from that idea. (Not permanently, of course, but it's the principal of the thing? Maybe?)

On the other hand...who knew that PCL/.NETStandard use would be so slow:

And the savings in build times for "Hello World", this is the Rebuild target:

• Debug + PCL - 8.424s
• Release + PCL - 13.651s
• Debug + not PCL - 4.258s
• Release + not PCL - 9.487s

Avoiding PCL's saves 30% (release) - 50% (debug). That's insane.

[jonathanpeppers]

Yeah this looks like a huge percentage for “Hello World”, but a real app might have build times well over a minute. Then the ~5 sec saving isn’t quite so huge (but still good).

I also suspect the change won’t quite as dramatic if tested with a release build of our build tasks.