[Hello-NativeAOTFromAndroid] Add NativeAOT+Android sample

[jonpryor]

Context: 2197579

Commit 2197579 added samples/Hello-NativeAOTFromJNI, which
demonstrated the use of NativeAOT to create a native library which
could be loaded and used by a Java application.

What else supports loading native libraries for use by a "Java"
environment? Android!

Take the core infrastructure from Hello-NativeAOTFromJNI, have
the binary output target linux-bionic-arm64 --
the $(RuntimeIdentifier) for .NET using Android's "bionic" libc
while not using .NET for Android -- and then use gradlew to
package that native library into an Android application.

Add "degrees" of Android and Gradle Integration:

• samples/Hello-NativeAOTFromAndroid/app is an Android project
  with Gradle build scripts.

• gradlew :app:processReleaseResources is executed as a pre-build
  step to get an R.txt describing all the Android Resources
  contained within the Android project. The new
  <ParseAndroidResources/> task parses R.txt and generates an
  R.g.cs, allowing C# code to reference some Android resources,
  such as the Android layout to display.

• android.xml contains a (very!) minimal API description of
  android.jar. It is used in a pre-build step to produce bindings
  of android.app.Activity and android.os.Bundle (among others),
  allowing us to write a C# subclass of Activity and show
  something on-screen.

• After the C# build, we:

  • use jcw-gen to generate Java Callable Wrappers (JCW) of
    Java.Lang.Object subclasses,
  • use jnimarshalmethod-gen to generate JNI marshal methods
    for methods such as MainActivity.OnCreate(), so that
    C# code can override Java methods.

• As a post-Publish step, we copy various artifacts into the
  Android project structure so that they can be packaged into the
  Android app-release.apk, then invoke gradlew assembleRelease
  to generate app-release.apk.

Update generator to support using Java.Base.dll as a referenced
assembly for binding purposes, in particular by supporting the use
of [JniTypeSignatureAttribute] on already bound types. No usable
bindings of types in android.xml could be generated without this.

Update jcw-gen to appropriately support
[JniTypeSignature(GenerateJavaPeer=false)] when determining the
constructors that a Java Callable Wrapper should contain. Failure to
do so meant that the JCW for MainActivity contained constructors
that shouldn't be there, resulting in javac errors.

Update jcw-gen to and support JavaInterop1-style method overrides.
Failure to do so meant that the JCW for MainActivity didn't
declare an onCreate() method.

[jonathanpeppers]

Overall, nothing seems too concerning. 👍

[jonathanpeppers]

if you wanted to remove:

Suggested change

	Console.WriteLine ($"C# init()");
	Console.WriteLine ("C# init()");

[jonpryor]

The C# compiler is able to optimize the former into the latter, meaning there isn't a reason to not use $"…" strings everywhere. This has the added benefit that you don't need to remember to add $ to your strings when you do want to use formatted strings, which is something I occasionally forget…

[jonathanpeppers]

Is this called by xamarin-android at all?

Just want to make sure we wouldn't make this too much worse:

• GenerateJavaStubs takes a long time when building incrementally for a maui project android#8920

I guess this could create an attribute instance, an IEnumerable, and then call .Any().

[jonpryor]

Yes this codepath is used by .NET for Android, in which case the problem with this change is that it could introduce additional object allocations that aren't needed. I'll look into updating this.