[XABT] Move JLO scanning needed for typemap generation to a linker step.

[jpobst]

Context: #9893
Context: #9930

This commit moves the process of scanning for JLOs needed for the typemap generation task to a new FindTypeMapObjectsStep "linker step".

The types are serialized to a new <assembly>.typemap.xml files that sits beside the source assembly. A new file was used rather than adding more sections to the .jlo.xml file because this file contains a lot more types and will likely change more often on incremental builds, and we don't want to trigger ie: creating new Java stubs when it isn't needed.

This file is then read in the existing <GenerateTypeMappings> to generate the final typemap file.

Like #9893, this temporarily leaves the old typemap generation code in place, guarded behind the $(_AndroidJLOCheckedBuild) flag. This flag generates the typemap both the new and old way, and errors the build if there are differences.

[jpobst]

A potential issue here is with cross-assembly duplicate detection.

Today, we are scanning all JLO derived types from all assemblies in a single loop, so duplicate detection logic like the following finds duplicates even if they are in different assemblies:

android/src/Xamarin.Android.Build.Tasks/Utilities/TypeMapCecilAdapter.cs

Lines 141 to 152 in 8c74126

	TypeMapDebugEntry oldEntry = duplicates [0];
	if ((td.IsAbstract || td.IsInterface) &&
	!oldEntry.TypeDefinition.IsAbstract &&
	!oldEntry.TypeDefinition.IsInterface &&
	td.IsAssignableFrom (oldEntry.TypeDefinition, cache)) {
	// We found the `Invoker` type *before* the declared type
	// Fix things up so the abstract type is first, and the `Invoker` is considered a duplicate.
	duplicates.Insert (0, entry);
	oldEntry.SkipInJavaToManaged = false;
	} else {
	// ¯\_(ツ)_/¯
	duplicates.Add (entry);

Because the new process only scans a single assembly at a time with Cecil, it will find duplicates in the same assembly, but not duplicates that may exist in other assemblies. An example is Java.Lang.Object:

Existing process:
- JavaName: "java/lang/Object" 
- ManagedName: "Java.Interop.JavaObject, Java.Interop" 
- SkipInJavaToManaged: "False" 
- DuplicateForJavaToManaged
  - JavaName: "java/lang/Object" 
  - ManagedName: "Java.Lang.Object, Mono.Android" 

New process:
- JavaName: "java/lang/Object" 
- ManagedName: "Java.Interop.JavaObject, Java.Interop" 
- SkipInJavaToManaged: "False" 
- DuplicateForJavaToManaged: null

It looks like we have 2 ordering semantics we have to preserve in replicating this logic:

• A declared type should take precedence over an "invoker" type.
• Types in Mono.Android should take precedence over other assemblies.

Aside from these 2 cases, which type is considered the "primary" and which type(s) are considered the "duplicates" seems to be luck of the draw.

[jonpryor]

@jpobst wrote:

type is considered the "primary" and which type(s) are considered the "duplicates" seems to be luck of the draw.

This is correct and incomplete. If you're only going by Java.Lang.Object.GetObject(handle), then you are correct.

However, most codepaths are not hitting Object.GetObject(IntPtr). Most codepaths are hitting Object.GetObject<T>(…) or Object.GetObject(…, Type targetType), which constrains which type that is used.

Thus, even if there are duplicate types (because bindings for a .jar are present in multiple assemblies), it generally won't matter because the APIs you're using will dictate the actual types used.