Introduce action for setting up running Android emulator

[rmartin16]

Changes

• Consolidates necessary logic for running the Android emulator in a GitHub action
• Outputs the necessary briefcase run android args to run the emulator in CI

PR Checklist:

• All new features have been tested
• All new features have been documented
• I have read the CONTRIBUTING.md file
• I will abide by the code of conduct

[rmartin16]

This PR includes implementing this new GitHub action in app-build-verify but it will also need to be implemented in Toga's CI and Python-support-testbed's CI. Once the new beeware/actions repo is running, it'll use this as well.

[freakboy3742]

@rmartin16 I just noticed this PR had slipped through the review cracks. My initial impression is that it makes sense - any recollection why (beyond "analogous changes needed in Toga etc") this was a draft?

[rmartin16]

This was part of (another one of..) my experiment for creating public-facing GitHub Actions. As part of that, I created the Action in this PR to consolidate this logic for Android.

However, then, we had the question of how such public Actions should interact with our "internal" Actions. Internally, we don't do any versioning and just kinda deal with the fallout from that (although, it isn't exactly "free" to introduce versioning...so, pro/con here). With public-facing Actions, we were thinking it might be more prudent to prevent updates to underlying Actions from just taking effect automatically in the public-facing ones. A thought, though, is if Dependabot will bump Git hashes; that is, if the public-facing Actions pin any underlying "internal" Actions with a commit hash, would Dependabot bump them to ensure we test such changes before they are exposed to users.

Anyway, that's where this is right now...