Need to support side-loaded typemap files

[jonpryor]

The typemap.jm and typemap.mj files are produced as part of the packaging process by TypeNameMapGenerator and the <GenerateJavaStubs/> task.

In order to help improve app performance (Issues #1443, #1829, #1830, #1831) we would like to require the presence and use of the typemap files, removing support for the Reflection-based fallback path, along with obsoleting Java.Interop.TypeManager.RegisterType(string, Type) and Java.Interop.TypeManager.RegisterPackage() and TypeManager.RegisterPackages().

However, in order to fully use typemap files, we need to support them in Fast Deployment scenarios. The problem is that the typemap files are currently stored as per-.apk data. As such, if a library assembly changes in a manner which requires updating the typemap files, the App.apk must be rebuilt and redeployed, if only to transfer the updated typemap files.

We need to update src/monodroid so that it will look for the typemap files in the .__override__ directories in addition to the .apk files. We can then generate typemap files as per-Assembly data and side-load them along with the corresponding assemblies, ensuring that when a new Assembly is deployed to the device we also deploy updated typemap files.

As a suggestion, we could name the per-assembly files as typemap-$(AssemblyBaseName).{jm,mj}, e.g. typemap-Mono.Android.jm and typemap-Mono.Android.mj.

[dellis1972]

The first part of this is done, the side loading support is in. We now need to look at generating type maps on a per assembly basis.

[grendello]

The second part, typemap generation and runtime support, is implemented in #3992