Android: Variant and Release Submodules

[souvlakias]

This implements #6047 (comment).

Changes

• AndroidModules now have inner Variant traits that share common tasks.
• AppModules also have Release traits which, for now, only override androidIsDebug to false.

Having a dedicated Variant for each module type (Android, AndroidKotlin, AndroidR8, AndroidNative) seems necessary to avoid missing configurations.

Users now need to create a release object that extends the corresponding Release trait, and then run: ./mill app.release.compile, etc

What's Next

Remove the androidIsDebug flag and instead let the Release traits override the relevant tasks directly.
Release configurations (keystore details) should be in the release variant too

Concerns

This approach utilizes shared resources and may provide a better user experience with the APIs. However in my opinion, manually overriding tasks to reference outer implementations may be error-prone, both in terms of development and potential unexpected behavior if users override unshared tasks.

Maybe the shared base trait approach is something safer and more scalable, but with the cost of not sharing resources. Perhaps we could use the outer approach —just as an exception— to share some resource-heavy tasks.

[vaslabs]

I think with this change, we should remove the defaults and avoid the comment above

[autofix-ci]

Hi! I'm autofix.ci, a bot that automatically fixes trivial issues such as code formatting in pull requests.

I would like to apply some automated changes to this pull request, but it looks like I don't have the necessary permissions to do so. To get this pull request into a mergeable state, please do one of the following two things:

1. Allow edits by maintainers for your pull request, and then re-trigger CI (for example by pushing a new commit).
2. Manually fix the issues identified for your pull request (see the GitHub Actions output for details on what I would like to change).

[vaslabs]

@lefou what do you think about this approach? Looking at the build variants in general, I think the cross module might be a better fit and perhaps we give a trait to easily achieve the release targets.

Just thinking out loud: For the variants in general the users are free to create a cross module themselves, but we should have something for release imo, but in this form a lot of the weight falls on us maintaining it while perhaps a different cross module approach than our first attempt would be better, for example having a AndroidCrossModule extends CrossModule[Android]("debug", "release") and then an AndroidReleaseModule extends AndroidCrossModule("release") or something in those lines (I haven't tried it yet)