[CoreCLR] support for debug build typemaps

[grendello]

Implements support for Debug configuration typemaps in CoreCLR apps.

This PR is limited to the managed-to-java lookup, as the java-to-managed one isn't
currently used in CoreCLR apps (that lookup is done in managed code, I will open a
new PR to experiment in this area).

This PR also doesn't implement support for fastdev, it will be addressed in a separate PR.

CoreCLR doesn't provide us with a way to translate a System.Type instance to a type name in
native code, and therefore the managed code calls into the native runtime to perform the lookup using the type name and the assembly MVID. However, the managed-to-java lookup tables use the assembly-qualified managed type name, so this PR introduces a step to "fix up" the
passed managed type name by appending the assembly name, which is obtained by searching for
MVID match in the MVID-to-name lookup table.

[grendello]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[grendello]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[jonpryor]

[CoreCLR] support for debug build typemaps (#10065)

Context: 684ede6a79da5b95eb9347c319683d8855f84d09
Context: b11471bc574876e148ff40757c5d273fd6fbde9e
Context: 7117414ca27d88a71b4a272705a0207f772423bd
Context: c227042b6e58565e21dcd5e4ff5ea20fc4e9367c
Context: a0a837afb6b638030bd9d4f73ccad50ee88f89bf
Context: ea38c0c1219bf8807947a6b68c3c7efc93ce18ff

From b11471bc:

> `Java.Interop.JniRuntime.JniTypeManager` supports bi-directional
> mapping between JNI type signatures and managed `Type`s:
> 
>   * `GetTypeSignature(Type)` returns the JNI type signature that
>     corresponds to the `System.Type`.
>   * `GetType(JniTypeSignature)` returns the `Type` that corresponds
>     to a JNI type signature.

We have had *multiple* ways to perform such mappings, including:

  * Fully managed (Release config):
    Processes trimmed assemblies, creates app-global mappings
    within `Mono.Android.dll`.
    Required for NativeAOT, optional with CoreCLR, MonoVM.
    Commits 684ede6a, b11471bc

  * MonoVM Instant Run (Debug config):
    Per-assembly mapping data, fast deployed to to the target device.
    Removed in commits 8298b6f7, 17e2e8ea.

  * MonoVM libxamarin-app.so (Debug config):
    Processes *un-trimmed* assemblies, creates app-global
    *string-based* type mappings within LLVM-IR, so that mappings
    don't need to be rebuilt as often when assemblies are changed.
    Commits 7117414c, c227042b

  * MonoVM libxamarin-app.so (Release config):
    Processes trimmed assemblies, creates app-global
    *assembly-based* type mappings within LLVM-IR, relying on
    assembly name hashes, assembly MVIDs, and type token IDs.
    Commits c227042b
  
  * CoreCLR libxamarin-app.so (Release config):
    Processes trimmed assemblies, creates app-global
    *assembly-based* type mappings within LLVM-IR, relying on
    assembly name hashes, assembly MVIDs, and type token IDs.
    Commits a0a837af, ea38c0c121

"Missing" from this list is support for Debug config CoreCLR builds.

Begin implementing managed-to-Java lookups for Debug config CoreCLR
builds by

 1. Updating `libxamarin-app.so` generation to emit data similar to
    the "MonoVM libxamarin-app.so (Debug config)" data structures, &

 2. Update `clr_typemap_managed_to_java()` /
    `TypeMapper::typemap_managed_to_java()` within
    `libmono-android.debug.so` to use the Debug config data in (1).

This allows (mostly) untrimmed assemblies to be used with typemap data.

Additionally, the managed-to-Java lookup tables use the
assembly-qualified managed type name; introduce a step to "fix up"
the passed managed type name by appending the assembly name, which is
obtained by searching for MVID match in the MVID-to-name lookup table.