WIP: Tests for the android-release-symbols branch

[jamescrosswell]

Tests to complete #4221:

• Fixes symbolication for net9.0-android applications in Release config #4221

Ideally we'd find a way to test this properly, since it snuck through our existing tests. I spent some time investigating a way to use the bundletool to split the AAB into device specific APKs (mimicking what happens when installing the app on a device)... and this might work but there are some subtleties/complexities.

When our current tests are running on an actual Android Device, they just get an Assembly Reader for the currently running application:

sentry-dotnet/test/Sentry.Android.AssemblyReader.Tests/AndroidAssemblyReaderTests.cs

Lines 26 to 29 in 13d4a9f

	#if ANDROID
	var logger = new TestOutputDiagnosticLogger(_output);
	return AndroidHelpers.GetAndroidAssemblyReader(logger)!;
	#else

I would expect, for a release build, that we would see the behaviour we see when running Sentry.Samples.Maui to a simulator in release mode... but we don't. So I'm guessing xharness takes some shortcuts or hosts the test app slightly differently. At the very least then, if we built some tests like this (using split APKs from the bundletool) we'd have to disable them when running on an Android device.

Also the bundle tool outputs a single *.apks file (APK Set). It's basically a zip and we can unpack it and it contains three files:

• toc.pb
• splits/base-master.apk
• splits/base-x86_64.apk

Curiously, these are not named base.apk and split_config.x86_64.apk... which is what I'm seeing when an app is actually installed on a device/simulator.

All in all, I wasn't building a lot of confidence that the tests were going to be useful... but this PR contains the preliminary work - build targets that use the bundletool to split the APKs.

#skip-changelog