Add new API for generating Project Specific Key for RegisterTaskObject

[dellis1972]

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

In dotnet/maui#11605, when $(AndroidEnableMarshalMethods)=True (dotnet/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() 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/>. The lifetime of .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 in the process, and also calls <GeneratePackageManagerJava/>.

In particular note the key within <GeneratePackageManagerJava/>: ".:!MarshalMethods!:.". This value is unchanged, 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 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.

Update the AndroidTask to capture the current directory in a WorkingDirectory property like AsyncTask does. Then introduce a new method ProjectSpecificTaskObjectKey which can be used to generate a key which includes the WorkingDirectory. Both AndroidTask and AndroidAsyncTask include this new method.

Allowing:

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

When ProjectSpecificTaskObjectKey is used the WorkingDirectory is included in the key with RegisterTaskObject(). This helps ensure that builds in different .csproj files will result in different keys.