Context: dotnet/android#4268

I was profiling builds with the Mono profiler and noticed:

	Method call summary
	Total(ms) Self(ms)      Calls Method name
	    70862       97      89713 Java.Interop.Tools.Cecil.DirectoryAssemblyResolver:Resolve (Mono.Cecil.AssemblyNameReference,Mono.Cecil.ReaderParameters)

Almost 90K calls to `DirectoryAssemblyResolver.Resolve()`?!
Where is that coming from???

	61422 calls from:
	    Java.Interop.Tools.Cecil.TypeDefinitionRocks/<GetTypeAndBaseTypes>d__1:MoveNext ()
	    Java.Interop.Tools.Cecil.TypeDefinitionRocks:GetBaseType (Mono.Cecil.TypeDefinition)
	    Mono.Cecil.TypeReference:Resolve ()
	    Mono.Cecil.ModuleDefinition:Resolve (Mono.Cecil.TypeReference)
	    Mono.Cecil.MetadataResolver:Resolve (Mono.Cecil.TypeReference)
	    Java.Interop.Tools.Cecil.DirectoryAssemblyResolver:Resolve (Mono.Cecil.AssemblyNameReference)

OK, this jogged my memory.  @StephaneDelcroix had mentioned one of
the big wins for the `<XamlC/>` task within Xamarin.Forms was to
cache any time `TypeReference.Resolve()` was called:

	https://github.com/xamarin/Xamarin.Forms/blob/1b9c22b4b9b1c1354a3a5c35ad445a2738c6f6c3/Xamarin.Forms.Build.Tasks/TypeReferenceExtensions.cs#L437-L443

`<XamlC/>` was able to use `static` here, because it's using a
feature of MSBuild to run in a separate `AppDomain`:

	https://github.com/xamarin/Xamarin.Forms/blob/1b9c22b4b9b1c1354a3a5c35ad445a2738c6f6c3/Xamarin.Forms.Build.Tasks/XamlTask.cs#L20-L21

However, I think we can simply add a new `TypeDefinitionCache` class
that would allow callers to control the caching strategy.  Callers
will need to control the scope of the `TypeDefinitionCache` so it
matches any `DirectoryAssemblyResolver` being used.  Right now most
Xamarin.Android builds will open assemblies with Mono.Cecil twice:
once for `<GenerateJavaStubs/>` and once for the linker.

We can add caching in an API-compatible way:

	[Obsolete ("Use the TypeDefinitionCache overload for better performance.")]
	public static TypeDefinition GetBaseType (this TypeDefinition type) =>
	    GetBaseType (type, cache: null);

	public static TypeDefinition GetBaseType (this TypeDefinition type, TypeDefinitionCache cache)
	{
	    if (bt == null)
	        return null;
	    if (cache != null)
	        return cache.Resolve (bt);
	    return bt.Resolve ();
	}

We just need to ensure `cache: null` is valid.  I took this approach
for any `public` APIs and made any `private` or `internal` APIs
*require* a `TypeDefinitionCache`.

I fixed every instance where `[Obsolete]` would cause a warning here
in Java.Interop.  We'll probably see a small improvement within
`generator` and `jnimarshalmethod-gen`.

Downstream in xamarin-android, in dotnet/android#4268 I
fixed all the `[Obsolete]` warnings that were present in
`<GenerateJavaStubs/>`.  I can make more changes for the linker in
a future PR.

~~ Results ~~

The reduced calls to `DirectoryAssemblyResolver.Resolve()`:

  * Before:

        Method call summary
        Total(ms) Self(ms)      Calls Method name
            70862       97      89713 Java.Interop.Tools.Cecil.DirectoryAssemblyResolver:Resolve (Mono.Cecil.AssemblyNameReference,Mono.Cecil.ReaderParameters)

  * After:

        Method call summary
        Total(ms) Self(ms)      Calls Method name
            68830       35      26315 Java.Interop.Tools.Cecil.DirectoryAssemblyResolver:Resolve (Mono.Cecil.AssemblyNameReference,Mono.Cecil.ReaderParameters)

~63,398 less calls.

In a build of the Xamarin.Forms integration project on macOS / Mono:

  * Before:

        1365 ms  GenerateJavaStubs                          1 calls

  * After:

         862 ms  GenerateJavaStubs                          1 calls

It is almost a 40% improvement, around ~500ms better.