[TrimmableTypeMap] Fix [Export] JNI signature mapping for non-primitive parameter types

[simonrozsival]

Part of #10933

Problem

The scanner's ManagedTypeToJniDescriptor() method maps managed types to JNI descriptors for [Export] method signatures. It correctly handles primitives (bool → Z, int → I, etc.) and string → Ljava/lang/String;, but falls back to Ljava/lang/Object; for all other types:

// Scanner/JavaPeerScanner.cs:1096-1097
// Fallback: any other type maps to Object
return "Ljava/lang/Object;";

This means [Export] methods with parameters like Android.Graphics.Bitmap, Java.Util.ArrayList, or any custom Java-bound type will get incorrect JNI signatures in the generated JCW.

Example

[Export("processImage")]
public void ProcessImage(Android.Graphics.Bitmap bitmap) { }

Expected JCW:

public void processImage(android.graphics.Bitmap p0) { n_processImage(p0); }
private native void n_processImage(android.graphics.Bitmap p0);

Actual JCW (with fallback):

public void processImage(java.lang.Object p0) { n_processImage(p0); }
private native void n_processImage(java.lang.Object p0);

Fix

The ManagedTypeToJniDescriptor() method needs to resolve Java-bound types by looking up their [Register] attribute to find the correct JNI type name. The type resolution can use the existing AssemblyIndex infrastructure to look up the target type's [Register] attribute.

Impact

Any [Export] method with non-primitive, non-string parameters will have an incorrect JNI signature. This will cause NoSuchMethodError at runtime when Java tries to call the exported method with the correct parameter types.