[build] Fix the Linux build (Take 2?)

[jonpryor]

As feared, commit 743529c's removal of $(TargetFrameworkRootPath)
broke the Linux build:

    Gui/Activities/TestSuiteActivity.cs(25,35): error CS0012: The type `System.IDisposable' is defined in an assembly that is not referenced.
    Consider adding a reference to assembly `System.Runtime, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'

macOS is unaffected as it's unfortunately using System files:

    Found framework definition list '/Library/Frameworks/Mono.framework/External/xbuild-frameworks/MonoAndroid/v1.0/RedistList/FrameworkList.xml' for framework 'MonoAndroid,Version=v1.0'

(Heavy sigh.)

Thus, our scenario: msbuild doesn't like our setting
$(TargetFrameworkRootPath), yet $(TargetFrameworkRootPath) needs
to be set for Linux+xbuild to work, because Linux+xbuild doesn't have
a system-wide Xamarin.Android install. (Not that we want to require a
Xamarin.Android install! But that's just why macOS is building...)

The fix? Split the difference, somewhat. We can't set
$(TargetFrameworkRootPath) for everything, but we can override
it for specific projects. Update Mono.Data.Sqlite.csproj,
Mono.Posix.csproj, OpenTK.csproj,
System.Drawing.Primitives.csproj,
System.EnterpriseServices.csproj, and
Xamarin.Android.NUnitLite.csproj to <Import/> the new
build-tools/scripts/MonoAndroidFramework.props file, which
overrides $(TargetFrameworkRootPath) and other MSBuild properties
appropriately, so that they resolve the MonoAndroid framework
assemblies from the internal build tree.

What's left is Mono.Android.csproj and Mono.Android.Export.csproj,
which don't <Import/> Xamarin.Android.CSharp.targets. These are
the projects that needed to "hack in" a @(Reference) to
System.Runtime in 7343965, which was removed in 743529c. The fix is
more voodoo in each of them:

• Set $(ImplicitlyExpandDesignTimeFacades)=False and provide a
  %(Reference.HintPath) value for System.Runtimeso that it can be found. We *don't* want$(ImplicitlyExpandDesignTimeFacades)`=True because that can cause
  all manner of madness on macOS, as it "implicitly expands
  facades", pulling in facades from both the internal build tree
  and the system-wide location. (Madness, and duplicate assembly
  reference errors, ensue.)
• Set $(TargetFrameworkIdentifier)=MonoAndroid, so we're looking for
  the correct framework.
• Set $(TargetFrameworkRootPath) so that the MonoAndroid framework
  can be found in the local build tree.
• Set $(TargetFrameworkVersion) to a valid MonoAndroid framework
  version number.

This allows Mono.Android.Export.csproj. Mono.Android.csproj needs
one more fix: in order for frameworks to be resolved from a "clean"
state, RedistList\FrameworkList.xml must exist before attempting to
resolve assemblies. Fix the _GenerateFrameworkList target so that
FrameworkList.xml is created before the ResolveReferences
target, thus allowing the MonoAndroid,v7.1 framework to be found.

One more final tidbit: MonoAndroidFramework.props and msbuild.mk
in concert use (and set) the new
$(_XAFixMSBuildFrameworkPathOverride) MSBuild property, which is set
when:

1. msbuild is being used, and
2. Mono is a version prior to Mono 4.8.

The msbuild included in Mono prior to 4.8 has a known bug where
$(FrameworkOverridePath) doesn't respect $(TargetFrameworkRootPath).
Without this fix, too many mscorlib.dll files are used in various
parts of the build process (via @(_ExplicitReference)), which causes
yet more sadness.

When using msbuild prior to Mono 4.8, explicitly set the
$(FrameworkOverridePath) property to a valid value.