Use the new RegisterTaskObject API

[dellis1972]

Bump to xamarin/xamarin-android-tools/main@099fd95 (#7709)

Context: dotnet/maui#11605
Context: dotnet/maui#11387 (comment)
Context: http://github.com/xamarin/xamarin-android/commit/8bc7a3e84f95e70fe12790ac31ecd97957771cb2

Changes: dotnet/android-tools@9f02d77...099fd95

• dotnet/android-tools@099fd95: Add *Task.ProjectSpecificTaskObjectKey() for RegisterTaskObject() use (Add new API for generating Project Specific Key for RegisterTaskObject android-tools#202)
• dotnet/android-tools@ac9ea09: Revert IBuildEngine.ProjectFileOfTaskNode use. (Revert IBuildEngine.ProjectFileOfTaskNode use. android-tools#201)
• dotnet/android-tools@47f95ab: Fix CS0121 ambiguity errors. (Fix CS0121 ambiguity errors. android-tools#200)
• dotnet/android-tools@76c076f: Add support for Project Specific RegisterTaskObject. (Add support for Project Specific RegisterTaskObject. android-tools#199)

In dotnet/maui#11605, when $(AndroidEnableMarshalMethods)=True
(8bc7a3e8), the build may fail if the .sln
contains more than one Android "App" project. We tracked this down
to "undesired sharing" between project builds; the obj provided to
IBuildEngine4.RegisterTaskObject() can be visible across
project builds. Consider <GeneratePackageManagerJava/>:

var marshalMethodsState = BuildEngine4.GetRegisteredTaskObjectAssemblyLocal<MarshalMethodsState> (".:!MarshalMethods!:.", RegisteredTaskObjectLifetime.Build);

Further consider a .sln with two "App" projects, as the "App"
project build hits <GeneratePackageManagerJava/>, e.g. the new
IncrementalBuildTest.BuildSolutionWithMultipleProjectsInParallel()
unit test. The lifetime of RegisteredTaskObjectLifetime.Build is
not tied to the the Build target of a given .csproj; rather,
it's for the build process. This can result in:

1. dotnet build Project.sln is run; Project.sln references
   App1.csproj and App2.csproj.
2. App1.csproj is built.
3. App1.csproj calls <GeneratePackageManagerJava/>.
4. App2.csproj is later built as part of the process, and also
   calls <GeneratePackageManagerJava/>.

In particular note the key within <GeneratePackageManagerJava/>:
".:!MarshalMethods!:.". This value is identical in all projects,
and means that that when App2.csproj is built, it will be using the
same key as was used with App1.csproj, and thus could be
inadvertently using data intended for App1.csproj!

This would result build errors:

…\Xamarin.Android.Common.targets(1717,3): error XAGPM7009: System.InvalidOperationException: Unable to translate assembly name 'Xamarin.AndroidX.Activity' to its index
…\Xamarin.Android.Common.targets(1717,3): error XAGPM7009:    at Xamarin.Android.Tasks.MarshalMethodsNativeAssemblyGenerator.WriteNativeMethods(LlvmIrGenerator generator, Dictionary`2 asmNameToIndex, LlvmIrVariableReference get_function_pointer_ref)
…\Xamarin.Android.Common.targets(1717,3): error XAGPM7009:    at Xamarin.Android.Tasks.MarshalMethodsNativeAssemblyGenerator.Write(LlvmIrGenerator generator)
…\Xamarin.Android.Common.targets(1717,3): error XAGPM7009:    at Xamarin.Android.Tasks.LLVMIR.LlvmIrComposer.Write(AndroidTargetArch arch, StreamWriter output, String fileName)
…\Xamarin.Android.Common.targets(1717,3): error XAGPM7009:    at Xamarin.Android.Tasks.GeneratePackageManagerJava.AddEnvironment()
…\Xamarin.Android.Common.targets(1717,3): error XAGPM7009:    at Xamarin.Android.Tasks.GeneratePackageManagerJava.RunTask()

The sharing of RegisterTaskObject() data across project builds is
rarely desirable. There are a few instances where it is safe to share
the registered objects between projects, e.g. java -version version
information (keyed on java path). However, most of the time it is
specific to the project that is being built. Historically we have
probably got away with this because "most" users only have one project.

dotnet/android-tools@099fd95 added the methods
AndroidTask.ProjectSpecificTaskObjectKey(object),
AndroidAsyncTask.ProjectSpecificTaskObjectKey(object), and
AndroidToolTask.ProjectSpecificTaskObjectKey(object) which returns
an object for use as the key to RegisteredTaskObject(), and the
value is a tuple which includes the input object and the
Directory.GetCurrentDirectory() value present when the task was
created. (Background note: when MSBuild builds a project, it calls
Directory.SetCurrentDirectory() to the directory of the current
project, which is why relative file paths to work in .csproj files.)

Review use of the MSBuildExtensions.RegisterTaskObjectAssemblyLocal()
extension method and audit the key value. If the registered value is
project specific, update the callsite to use
ProjectSpecificTaskObjectKey(object), ensuring that project-specific
data is not accidentally reused in a different project.

[jonpryor]

WIP commit message:

Bump to xamarin/xamarin-android-tools/main@099fd95 (#7709)

Context: https://github.com/dotnet/maui/issues/11605
Context: https://github.com/dotnet/maui/pull/11387#issuecomment-1318738792
Context: http://github.com/xamarin/xamarin-android/commit/8bc7a3e84f95e70fe12790ac31ecd97957771cb2

Changes: https://github.com/xamarin/xamarin-android-tools/compare/9f02d77692bca8c6585941de03750d5eaaca5c5a...099fd95f5459d9df78af0ad28f46e3016dd7ca1d

  * xamarin/xamarin-android-tools@099fd95: Add *Task.ProjectSpecificTaskObjectKey() for RegisterTaskObject() use (xamarin/xamarin-android-tools#202)
  * xamarin/xamarin-android-tools@ac9ea09: Revert IBuildEngine.ProjectFileOfTaskNode use. (xamarin/xamarin-android-tools#201)
  * xamarin/xamarin-android-tools@47f95ab: Fix CS0121 ambiguity errors. (xamarin/xamarin-android-tools#200)
  * xamarin/xamarin-android-tools@76c076f: Add support for Project Specific RegisterTaskObject. (xamarin/xamarin-android-tools#199)

In dotnet/maui#11605, when `$(AndroidEnableMarshalMethods)`=True
(xamarin/xamarin-android@8bc7a3e8), the build may fail if the `.sln`
contains more than one Android "App" project.  We tracked this down
to "undesired sharing" between project builds; the `obj` provided to
[`IBuildEngine4.RegisterTaskObject()`][0] can be visible across
project builds.  Consider [`<GeneratePackageManagerJava/>`][1]:

	var marshalMethodsState = BuildEngine4.GetRegisteredTaskObjectAssemblyLocal<MarshalMethodsState> (".:!MarshalMethods!:.", RegisteredTaskObjectLifetime.Build);

Further consider a `.sln` with two "App" projects, as the "App"
project build hits `<GeneratePackageManagerJava/>`, e.g. the new
`IncrementalBuildTest.BuildSolutionWithMultipleProjectsInParallel()`
unit test.  The lifetime of `RegisteredTaskObjectLifetime.Build` is
*not* tied to the the `Build` target of a given `.csproj`; rather,
it's for the *build process*.  This can result in:

 1. `dotnet build Project.sln` is run; `Project.sln` references
    `App1.csproj` and `App2.csproj`.
 2. `App1.csproj` is built.
 3. `App1.csproj` calls `<GeneratePackageManagerJava/>`.
 4. `App2.csproj` is later built as part of the process, and *also*
    calls `<GeneratePackageManagerJava/>`.

In particular note the key within `<GeneratePackageManagerJava/>`:
`".:!MarshalMethods!:."`.  This value is identical in all projects,
and means that that when `App2.csproj` is built, it will be using the
same key as was used with `App1.csproj`, and thus could be
inadvertently using data intended for `App1.csproj`!

This would result build errors:

	…\Xamarin.Android.Common.targets(1717,3): error XAGPM7009: System.InvalidOperationException: Unable to translate assembly name 'Xamarin.AndroidX.Activity' to its index
	…\Xamarin.Android.Common.targets(1717,3): error XAGPM7009:    at Xamarin.Android.Tasks.MarshalMethodsNativeAssemblyGenerator.WriteNativeMethods(LlvmIrGenerator generator, Dictionary`2 asmNameToIndex, LlvmIrVariableReference get_function_pointer_ref)
	…\Xamarin.Android.Common.targets(1717,3): error XAGPM7009:    at Xamarin.Android.Tasks.MarshalMethodsNativeAssemblyGenerator.Write(LlvmIrGenerator generator)
	…\Xamarin.Android.Common.targets(1717,3): error XAGPM7009:    at Xamarin.Android.Tasks.LLVMIR.LlvmIrComposer.Write(AndroidTargetArch arch, StreamWriter output, String fileName)
	…\Xamarin.Android.Common.targets(1717,3): error XAGPM7009:    at Xamarin.Android.Tasks.GeneratePackageManagerJava.AddEnvironment()
	…\Xamarin.Android.Common.targets(1717,3): error XAGPM7009:    at Xamarin.Android.Tasks.GeneratePackageManagerJava.RunTask()

The sharing of `RegisterTaskObject()` data across project builds is
rarely desirable.  There are a few instances where it is safe to share
the registered objects between projects, e.g. `java -version` version
information (keyed on `java` path).  However, most of the time it is
specific to the project that is being built.  Historically we have
probably got away with this because "most" users only have one project.

xamarin/xamarin-android-tools@099fd95 added the methods
`AndroidTask.ProjectSpecificTaskObjectKey(object)`, 
`AndroidAsyncTask.ProjectSpecificTaskObjectKey(object)`, and
`AndroidToolTask.ProjectSpecificTaskObjectKey(object)` which returns
an `object` for use as the key to `RegisteredTaskObject()`, and the
value is a tuple which includes the input `object` *and* the
`Directory.GetCurrentDirectory()` value present when the task was
created.  (Background note: when MSBuild builds a project, it calls
`Directory.SetCurrentDirectory()` to the directory of the current
project, which is why relative file paths to work in `.csproj` files.)

Review use of the `MSBuildExtensions.RegisterTaskObjectAssemblyLocal()`
extension method and audit the key value.  If the registered value is
project specific, update the callsite to use
`ProjectSpecificTaskObjectKey(object)`, ensuring that project-specific
data is not accidentally reused in a different project.

[0]: https://learn.microsoft.com/en-us/dotnet/api/microsoft.build.framework.ibuildengine4.registertaskobject?view=msbuild-17-netcore
[1]: https://github.com/xamarin/xamarin-android/blob/c92ae5eb9fdcb3a2fd7c20f5b42dddf8b3ea781a/src/Xamarin.Android.Build.Tasks/Tasks/GeneratePackageManagerJava.cs#L407
[2]: https://github.com/xamarin/Xamarin.Build.AsyncTask/blob/8b5fc6c4d13a3dfd1d17a2007e2143b6da3447d7/Xamarin.Build.AsyncTask/AsyncTask.cs#L59