Add enable_android_sdk_checks option for Android emulator testing

[marcprux]

The Android CI added in #172 will build against the Swift SDK for Android using the scripts/install-and-build-with-sdk.sh support for building with cross-compilation SDKs, but it does't actually test the package. This PR adds a scripts/android/android-emulator-tests.sh script that will install and configure an Android emulator and then transfer the test cases over to it and run the tests on the emulator.

Notes:

• In addition to the build-only enable_android_sdk_build input to workflows/swift_package_test.yml, we now have an enable_android_sdk_checks boolean which will additionally run a package's test cases.
• The Android emulator requires KVM to be enabled for acceleration, which is not possible in a nested docker container. I saw no reason why the SDK build needs to take place in a nested container, so I moved it to run on the top-level ubuntu-latest container.
• The emulator will only run on x86_64; since we support building against multiple triples (currently defaulting to aarch64-unknown-linux-android28 and x86_64-unknown-linux-android28 in workflows/swift_package_test.yml), we will still build against each of these archs, but only test against x86_64.
• As mentioned previously (Add Android emulator testing to workflow #179 (comment)), not all package testing will pass out of the box, since some tests rely on hardcoded #filePath references to test data (e.g., in swift-crypto), which will not work when the tests are run in an emulator with a separate filesystem. I expect that some of these packages will need to be updated if we are to enable enable_android_sdk_checks for them.

A successful run can be seen at https://github.com/swift-android-sdk/github-workflows/actions/runs/20244304679/job/58120240667

Closes #179 and #83

CC: @finagolfin, @justice-adams-apple, @etcwilde, @shahmishal

[finagolfin]

If multiple triples are passed in, what does this do, just grab the API level of the first one?

[marcprux]

The last one, actually.

[finagolfin]

If multiple triples are passed in, what does this do, just grab the arch of the first one? If we only support x86_64 right now, may be better to just hard-code this until we support testing on other arches, or it may fail if it attempts those.

[marcprux]

It will actually grab the arch of the last one that is passed in (just because of how the parameter is iterated; the last one "wins"). So it happens to work with the default triples that we build against:

github-workflows/.github/workflows/swift_package_test.yml

Lines 150 to 153 in 20b826e

	android_sdk_triples:
	type: string
	description: "The triples to use when building with the Swift SDK for Android"
	default: "[\"aarch64-unknown-linux-android28\", \"x86_64-unknown-linux-android28\"]"

I had considered just hardwiring "x86_64", but it is possible that aarch64 will work someday once they release a Linux ARM64 emulator (and it currently does work on macOS, which leaves open the possibility of running this on a self-hosted runner).

In the (unlikely, methinks) event of someone overriding the build triples to not include x86_64, then this workflow won't currently work at all, since we expect that the package tests will already have been built by install-and-build-with-sdk.sh.

If we want to make this less magic, we could add another parameter to swift_package_test.yml, like:

 android_sdk_checks_emulator_image:
   type: string 
   description: "The emulator system image for testing package with the Swift SDK for Android" 
   default: "system-images;android-28;default;x86_64" 

That would allow complete fine-grained control over the exact emulator image that is being used.

[finagolfin]

Your choice: either add that image setting and add some logic to make sure it matches one of the SDK triples, or simply document in the description that the testing will always be done with the parameters from the last SDK triple specified, so that those who do override the SDK triples won't be surprised by the resulting CI failures.