[build] Add support for Configuration.Override.props

[jonpryor]

For proper use, the xamarin-android build needs to place various
Java.Interop utilities such as class-parse.exe and generator.exe into
$prefix/lib/mandroid, so that Xamarin.Android.Build.Tasks.dll will
properly verify the installation environment.

There are three ways this could be accomplished:

1. The xamarin-android Makefile could explicitly build these
   utilities and override $(OutputPath):

   xbuild external/Java.Interop/tools/class-parse /p:OutputPath=`pwd`/bin/$(CONFIGURATION)/lib/mandroid
   

   The problem with this is that we want to have the xamarin-android
   build system rely on MSBuild as much as possible, and this
   approach, while workable, runs counter to those desires.

2. We could add additional project configurations to control where the
   output directory should be. This was suggested by
   @atsushieno.

   My concern with this approach is that it's not easily extensible:
   it's not just a few projects that need to place files into
   $prefix/lib/mandroid, but all of their dependencies as well.
   Such an approach would thus require adding lots of new
   configurations to lots of projects.

3. Java.Interop could adopt a xamarin-android-style
   Configuration.props system. This would allow xamarin-android to
   generate a Configuration.Override.props file to specify the
   correct output path for those utilities.

(3) is the chosen solution. It allows adding e.g.
external/Java.Interop/tools/generator/generator.csproj to
Xamarin.Android.sln, allowing it to be built "normally" from the
xamarin-android build system, while causing the built files to be
placed into e.g. xamarin-android/bin/Debug/lib/mandroid instead of
the less useful xamarin-android/external/Java.Interop/bin/Debug.

[radical]

Maybe you can add:

<PropertyGroup>
   <Configuration Condition="'$(Configuration)' == ''">ConfigurationNotSetInConfigurationPropsForProject-$(MSBuildProjectFile)</Configuration>
</PropertyGroup>

[jonpryor]

That'll result in obscure/bizarre errors, as a non-existent configuration could be used for building:

<!-- "bad" .csproj -->
<Project ...>
  <Import Project="..\..\Configuration.props" />
  <PropertyGroup>
    <Configuration Condition=" '$(Configuration)' == '' ">Debug</Configuration>
  </PropertyGroup>
  <PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|AnyCPU' " />
  <PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|AnyCPU' " />
</Project>

With such a "bad" project, $(Configuration) will be set, causing MSBuild to look for the ConfigurationNotSetInConfigurationPropsForProject|AnyCPU configuration, which doesn't exist.

At best, it'll still compile but you have no idea where the output file is.

More likely -- if #if is used at all -- is that the project will fail to build with some "bizarro" error that in no way suggests that the error is "an invalid $(Configuration) value was specified, dummy!".

[radical]

Um.. shouldn't $(UtilityOutputFullPath) be the "public" property, instead of $(UtilityOutputPath) ?

[jonpryor]

Indeed!

[radical]

um and accordingly this (bin/$(Configuration)) should be updated to show an absolute path or explicitly mention that here.

[radical]

Other than the doc related comment, LGTM!