[Xamarin.Android.Build.Tasks] Add $(AndroidErrorOnCustomJavaObject)

[jonpryor]

Fixes: https://bugzilla.xamarin.com/show_bug.cgi?id=56819

Bumps to Java.Interop/master/ab3c2b26.

Nothing prevents "anybody" from custom implementing IJavaObject:

class MyBadClass : Android.Runtime.IJavaObject {
    public IntPtr Handle {
        get {return IntPtr.Zero;}
    }

    public void Dispose () {}
}

The problem is that the above doesn't actually work: the
IJavaObject.Handle value contains the JNI Object Reference to pass
into JNI. The above code will thus result in always passing null
into Java code, which could result in a NullPointerException, but
will always result in not doing what was intended.

While it is theoretically possible to manually implement
IJavaObject, it's not something I would want to contemplate, nor
is it for the faint of heart, so long ago we decided to emit a warning
if we encounter a type which:

1. Implements Android.Runtime.IJavaObject, and
2. Does not also inherit Java.Lang.Object or
   Java.Lang.Throwable.

As such, the above MyBadClass elicits the warning:

Type 'MyBadClass' implements Android.Runtime.IJavaObject but does not inherit from Java.Lang.Object. It is not supported.

This is all well and good, but (effectively) nobody reads warnings,
especially since our toolchain emits so many warnings that enabling
/warnaserror is for the truly foolhardy, so lots of warnings is,
unfortunately, normal.

Which brings us to Bug #56819: Could we make this an error?

Answer: Of course we can. That said, I have no idea how much existing
code this will break if we turned it into an error. That might be
good and useful, but if there's no way to disable the error,
existing apps which (appear to) work will no longer build.

That's not desirable.

Add a new $(AndroidErrorOnCustomJavaObject) MSBuild property to
control what happens when such custom IJavaObject implementations
are found. When True, the default, emit a new XA4212 error.
The error can be turned back into a warning by setting
$(AndroidErrorOnCustomJavaObject) within the App.csproj:

<!-- Within App.csproj -->
<PropertyGroup>
  <AndroidErrorOnCustomJavaObject>False</AndroidErrorOnCustomJavaObject>
</PropertyGroup>

[dellis1972]

@jonpryor not sure we can use it here. Doing that in any Task which uses AsyncTask will lock the UI in VS because we cannot use Log on a background thread. So that code was probably an accident waiting to happen anyway.

[dellis1972]

We should probably have an overload which takes the AsyncTask and uses the LogError and LogWarning methods on that class.

[jonpryor]

NOW WITH UNIT TESTS

Which actually found several typo's....