RFC: New `UpdateCheckMode`, `GradleTask`, to support nightly builds

This would solve the issue described in #388, and allow developers to provide "nightly" or other custom builds of their apps without needing to operate a separate repository.

Background

AIUI, developers can't easily provide a "nightly" or similar build of their app in F-Droid without providing a mechanism for F-Droid to notice that the app has been updated. Those options are (https://f-droid.org/en/docs/Build_Metadata_Reference/#UpdateCheckMode):

• RepoManifest
• RepoTrunk
• Tags
• HTTP

None of those (except RepoTrunk, which needs svn or git-svn) support automatically building the latest commit without the development team also need to do something; e.g., having to tag each commit, or update the manifest file, or maintain an external file that can be fetched with http.

So the current recommendation for teams that want to support a nightly build of their app is to produce it out of their CI (https://f-droid.org/docs/Publishing_Nightly_Builds/), and have a separate repository for the nightly build.

Proposal

Gradle supports overriding Android properties, including the versionCode and versionName at build time, for one or more build variants.

For example, https://github.com/tuskyapp/Tusky/pull/3896 derives the versionCode for the "green" (aka "nightly") Tusky release from the git commit count.

Unfortunately, gradle does not let you query for this information from the command line. However, developers could add a custom task that does this. For example:

applicationVariants.configureEach { variant ->
    tasks.register("printVersionInfo${variant.name.capitalize()}") {
        notCompatibleWithConfigurationCache("Should always print the version info")
        println variant.versionCode + " " + variant.versionName
    }
}

This task can then be run (examples are from Tusky at the time of writing)

% ./gradlew -q printVersionInfoBlueDebug  # debug build, regular (non-nightly)
113 23.0
% ./gradlew -q printVersionInfoGreenRelease  # release build, nightly
10687 23.0-e62a9d0f

Critically, this completes in milliseconds -- there is no need for the full build (debug, or release) to complete, so it's very cheap.

This could be used by F-Droid to determine whether the version code has changed and a new release should be made.

To do this:

1. Add a new UpdateCheckMode option, which I suggest calling GradleTask.
2. Extend UpdateCheckData. When the check mode is GradleTask, UpdateCheckData is mandatory, and is expected to contain the full name of the gradle task that prints the space-separated versionCode and versionName for this release.

With this, I would be able to add a com.keylesspalace.tusky.test.yml file to the metadata repository with this at the bottom:

# ...
AutoUpdateMode: Version
UpdateCheckMode: GradleTask
UpdateCheckData: printVersionInfoGreenRelease

and if I've followed the update check process correctly, this would see that the version code has changed on each commit, and build the new version.