[ci] Upgrade on-prem macOS pool to macOS-14 Sonoma (#9477)

Build and test stages using the physical macOS pool have been updated to
use macOS-14 Sonoma images, and builds will now prefer Apple silicon
over Intel machines.

[native/monodroid] Fix unmangling of satellite assembly names (#9533)

Fixes: #9532

Context: #9410
Context: 86260ed
Context: c927026

In Debug configuration builds, `$(EmbedAssembliesIntoApk)`=false by
default.  This enables Fast Deployment in commercial/non-OSS builds.

When `$(EmbedAssembliesIntoApk)`=true, there are two separate ways to
embed assemblies into the `.apk`:

  * Assembly Stores (c927026), which is a "single" (-ish) file that
    contains multiple assemblies, enabled by setting
    `$(AndroidUseAssemblyStore)`=true.

    This is the default behavior for Release configuration builds.

  * One file per assembly (86260ed).

    This is the default behavior for Debug configuration builds when
    `$(EmbedAssembliesIntoApk)`=true.

Aside: #9410 is an attempt to *remove* support for the
"one file per assembly" packaging strategy, which will *not* be
applied to release/9.0.1xx.

When using the "one file per assembly" strategy, all the assemblies
are wrapped in a valid ELF shared library image and placed in the
`lib/{ABI}` directories inside the APK/AAB archive.  Since those
directories don't support subdirectories, we need to encode satellite
assembly culture in a way that doesn't use the `/` directory
separator char.

This encoding, as originally implemented, unfortunately used the `-`
character which made it ambiguous with culture names that consist of
two parts, e.g. `de-DE`, since the unmangling process would look for
the first occurrence of `-` to replace it with `/`, which would form
invalid assembly names such as `de/DE-MyAssembly.resources.dll`
instead of the correct `de-DE/MyAssembly.resources.dll`.  This would,
eventually, lead to a mismatch when looking for satellite assembly for
that specific culture.

Fix it by changing the encoding for `/` from `-` to `_`, so that the
mangled assembly name looks like
`lib_de-DE_MyAssembly.resources.dll.so` and we can unambiguously
decode it to the correct `de-DE/MyAssembly.resources.dll` name.

[Xamarin.Android.Build.Tasks] Add retry ability to RemoveDirFixed (#9409

)

Fixes: #9133

Context: dotnet/android-tools@60fae19

Much to our chagrin, in .NET 6+ it is possible for Design-Time Builds
(DTBs) to run concurrently with "normal" builds, as there is nothing
within the [.NET Project System][0] or [Common Project System (CPS)][1]
which would actively *prevent* such concurrency.

Consequently, it is possible to encounter locked files and
directories during the build process, and user may see errors such as:

	Error (active)	XARDF7019	System.UnauthorizedAccessException: Access to the path 'GoogleGson.dll' is denied.
	   at System.IO.Directory.DeleteHelper(String fullPath, String userPath, Boolean recursive, Boolean throwOnTopLevelDirectoryNotFound, WIN32_FIND_DATA& data)
	   at System.IO.Directory.Delete(String fullPath, String userPath, Boolean recursive, Boolean checkHost)
	   at Xamarin.Android.Tasks.RemoveDirFixed.RunTask() in /Users/runner/work/1/s/xamarin-android/src/Xamarin.Android.Build.Tasks/Tasks/RemoveDirFixed.cs:line 54	MauiApp2 (net9.0-android)	C:\Program Files\dotnet\packs\Microsoft.Android.Sdk.Windows\34.99.0-preview.6.340\tools\Xamarin.Android.Common.targets	2503

dotnet/android-tools@60fae192 introduced the concept of a "Retry" in
the cases of `UnauthorizedAccessException`s or `IOException`s when
the code is `ACCESS_DENIED` or `ERROR_SHARING_VIOLATION`.

Builds upon that work to use the API's added to add retry semantics
to the `<RemoveDirFixed/>` task. 

This also simplifies the Task somewhat as it had quite complex
exception handling. 

[0]: https://github.com/dotnet/project-system
[1]: https://github.com/microsoft/VSProjectSystem

Bump to xamarin/monodroid@b753d75f (#9415)

Changes: xamarin/monodroid@352bcbe...b753d75

Updates the recommended Android SDK component feed to the latest d17-12
version.

LEGO: Pull request (#9358)

LEGO: Pull request from juno/hb_6dddf33b-c6da-43d8-ac04-14d2c339cb00_20241002103533710 to main with localized lcls

[tests] add test for `$(AdbTargetArchitecture)` (#9227) (#9317)

Backport of: #9227
Context: #8662
Context: xamarin/monodroid#1537

* Bump to xamarin/monodroid@352bcbe8

Changes: xamarin/monodroid@1a9ee37...352bcbe

* [tools/msbuild] implement $(AdbTargetArchitecture) for IDEs

* Bump to c158adfd6f

Bump to dotnet/runtime@c4d7f7c6f2 9.0.0-rc.1.24431.7 (#9274)

Changes: dotnet/runtime@a7d6f0c...c4d7f7c
Changes: dotnet/emsdk@459c929...08499c1

Updates:

* Microsoft.NET.ILLink.Tasks: from 9.0.0-rc.1.24430.5 to 9.0.0-rc.1.24431.7
* Microsoft.NETCore.App.Ref: from 9.0.0-rc.1.24430.5 to 9.0.0-rc.1.24431.7
* Microsoft.NET.Workload.Emscripten.Current.Manifest-9.0.100.Transport: from 9.0.0-rc.1.24420.5 to 9.0.0-rc.1.24430.3

Bump to dotnet/runtime@2d5c0b72 8.0.8 (#9266)

Reverts 732db0c
Reverts e039014

[installers] Ship `NuGet*` files needed by `<AndroidMavenLibrary>` (#…

…9098)

Fixes: #9037

Attempting to use `@(AndroidMavenLibrary)` in Visual Studio 17.11 P3,
which ships .NET 9 P5, like this:

	<ItemGroup>
	  <AndroidMavenLibrary Include="com.squareup.okhttp3:okhttp" Version="4.9.3" />
	</ItemGroup>

gives you the error:

	…\Microsoft.Android.Sdk.Windows\34.99.0-preview.5.308\tools\Xamarin.Android.Bindings.JavaDependencyVerification.targets(27,5): error XAJDV7028: System.IO.FileNotFoundException: Could not load file or assembly 'NuGet.ProjectModel, Version=6.9.1.3, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies. The specified file cannot be found.
	…\Microsoft.Android.Sdk.Windows\34.99.0-preview.5.308\tools\Xamarin.Android.Bindings.JavaDependencyVerification.targets(27,5): error XAJDV7028: File name: 'NuGet.ProjectModel, Version=6.9.1.3, Culture=neutral, PublicKeyToken=31bf3856ad364e35'
	…\Microsoft.Android.Sdk.Windows\34.99.0-preview.5.308\tools\Xamarin.Android.Bindings.JavaDependencyVerification.targets(27,5): error XAJDV7028:    at Xamarin.Android.Tasks.NuGetPackageVersionFinder.Create(String filename, TaskLoggingHelper log)
	…\Microsoft.Android.Sdk.Windows\34.99.0-preview.5.308\tools\Xamarin.Android.Bindings.JavaDependencyVerification.targets(27,5): error XAJDV7028:    at Xamarin.Android.Tasks.DependencyResolver..ctor(String lockFile, TaskLoggingHelper log) in /Users/runner/work/1/s/xamarin-android/src/Xamarin.Android.Build.Tasks/Tasks/JavaDependencyVerification.cs:line 124
	…\Microsoft.Android.Sdk.Windows\34.99.0-preview.5.308\tools\Xamarin.Android.Bindings.JavaDependencyVerification.targets(27,5): error XAJDV7028:    at Xamarin.Android.Tasks.JavaDependencyVerification.RunTask() in /Users/runner/work/1/s/xamarin-android/src/Xamarin.Android.Build.Tasks/Tasks/JavaDependencyVerification.cs:line 77
	…\Microsoft.Android.Sdk.Windows\34.99.0-preview.5.308\tools\Xamarin.Android.Bindings.JavaDependencyVerification.targets(27,5): error XAJDV7028:    at Microsoft.Android.Build.Tasks.AndroidTask.Execute() in /Users/runner/work/1/s/xamarin-android/external/xamarin-android-tools/src/Microsoft.Android.Build.BaseTasks/AndroidTask.cs:line 25

We need to ship `NuGet.ProjectModel.dll` as well as its dependencies
to ensure they are always available to our MSBuild tasks.

Note that NuGet does not ship `.pdb` files for these assemblies in
their NuGet packages.  We will need to exclude these assemblies from
`.pdb` checking.

This wasn't caught by CI because CI tests use `dotnet build`, *not*
Visual Studio, and the `dotnet` install contains `NuGet.ProjectModel`
and related dependencies:

	% find bin/Debug/dotnet -iname NuGet.Project\*
	bin/Debug/dotnet/sdk/…/Sdks/Microsoft.NET.Sdk/tools/net472/NuGet.ProjectModel.dll
	bin/Debug/dotnet/sdk/…/NuGet.ProjectModel.dll
	…

Bump to dotnet/sdk@89054b0c37 9.0.100-preview.6.24325.8 (#9059)

Changes: dotnet/sdk@3c7b1bd...89054b0

Updates: VS.Tools.Net.Core.SDK.Resolver: from 9.0.100-preview.6.24324.9 to 9.0.100-preview.6.24325.8