[Java.Interop] GetSimpleReferences():fallback for GetTypeSignatures()

[jonpryor]

Context: dotnet/android#9768

dotnet/android#9768 attempts to add types from Java.Interop.dll to the .NET for Android typemaps, in order to fix Debug warnings like:

I monodroid-assembly: typemap: unable to find mapping to a Java type from managed type 'Java.Interop.ManagedPeer, Java.Interop'

Unfortunately, this causes the assertion:

AssertGetJniTypeInfoForType (typeof (JavaArray<JavaObject>),    "[Ljava/lang/Object;",  false,  1);

within Java.InteropTests.JniTypeManagerTests.GetTypeSignature_Type() to fail:

Expected string length 19 but was 33. Strings differ at index 0.
Expected: "[Ljava/lang/Object;"
But was:  "crc64d5d92128469ae06d/JavaArray_1"
-----------^

The immediate cause of the failure is that
JniRuntime.JniTypeManager.GetTypeSignature() called JniRuntime.JniTypeManager.GetSimpleReference() before it tried to see if the type was JavaArray<T>. As Java.Interop.dll was now being processed for typemap purposes, and because JavaArray<T> did not have a [JniTypeSignatureAttribute], the typemap got the default behavior of crc64[hash…].

The broader cause is that GetSimpleReference() should be the fallback implementation, used after all other attempts to get a JNI name have failed.

Update GetTypeSignature() and GetTypeSignatures() so that GetSimpleReference() and/or GetSimpleReferences() are in fact treated as fallbacks.

Additionally, update AssertGetJniTypeInfoForType() to assert that the value returned by GetTypeSignature() is the same as the value return3ed by GetTypeSignatures().First(). This was commented as being the case, but we should verify that as well.

Finally, update AssertGetJniTypeInfoForType() so that when the assertion fails, the source type value is provided.

[jonpryor]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[jonpryor]

Draft commit message:

[Java.Interop] GetSimpleReferences(): fallback for GetTypeSignatures()

Context: https://github.com/dotnet/android/pull/9768

dotnet/android#9768 attempts to add types from `Java.Interop.dll` to
the .NET for Android typemaps, in order to fix Debug warnings like:

	I monodroid-assembly: typemap: unable to find mapping to a Java type from managed type 'Java.Interop.ManagedPeer, Java.Interop'

Unfortunately, the initial attempt to generate typemaps for
`Java.Interop.dll` caused the assertion:

	AssertGetJniTypeInfoForType (typeof (JavaArray<JavaObject>),    "[Ljava/lang/Object;",  false,  1);

within `Java.InteropTests.JniTypeManagerTests.GetTypeSignature_Type()`
to fail with:

	Expected string length 19 but was 33. Strings differ at index 0.
	Expected: "[Ljava/lang/Object;"
	But was:  "crc64d5d92128469ae06d/JavaArray_1"
	-----------^

The immediate cause of the failure is that
`JniRuntime.JniTypeManager.GetTypeSignature()` called
`JniRuntime.JniTypeManager.GetSimpleReference()` *before* it tried
to see if the type was `JavaArray<T>`.  As `Java.Interop.dll` was now
being processed for typemap purposes, and because `JavaArray<T>` did
not have a `[JniTypeSignatureAttribute]`, the typemap got the default
behavior of `crc64[hash…]`.

The broader cause is that `GetSimpleReference()` should be the
*fallback* implementation, used after all other attempts to get a
JNI name have failed.

Update `GetTypeSignature()` and `GetTypeSignatures()` so that
`GetSimpleReference()` and/or `GetSimpleReferences()` are in fact
treated as fallbacks.

Additionally, update `AssertGetJniTypeInfoForType()` to assert that
the value returned by `GetTypeSignature()` is the same as the value
return3ed by` GetTypeSignatures().First()`.  This was *commented* as
being the case, but we should *verify* that as well.

Finally, *move* the
`type.GetCustomAttribute<JniTypeSignatureAttribute()` and
`GetReplacementType()` logic into `GetSimpleReferences()`.  This 
This emphasizes the "fallback" nature of `GetSimpleReference()`,
adds an missing `GetReplacementType()` invocation from the
`GetTypeSignatures()` codepath, and this is what
[`AndroidTypeManager.GetSimpleReference()`][0] was already doing.

[0]: https://github.com/dotnet/android/blob/21c413195e300b6440eb437dade4f3a114e795f7/src/Mono.Android/Android.Runtime/AndroidRuntime.cs#L279-L289

Copilot reviewed 4 out of 4 changed files in this pull request and generated no comments.

Copilot reviewed 4 out of 4 changed files in this pull request and generated no comments.