…rsion` and `compileSdkVersion` properties

…argetSdk` and `compileSdkVersion` to `compileSdk` in `build.gradle` files

`compileSdkVersion` was deprecated in Android gradle plugin (`AGP`) version `>= 7.2.0` in favour of `compileSdk`, so replace `Version` suffix from other related variables as well to be consistent.

- https://developer.android.com/reference/tools/gradle-api/7.2/com/android/build/api/dsl/CommonExtension#compileSdkVersion(kotlin.Int)

… GitHub release builds, and update `github_action_build` (previously `debug_build`) workflow and `app/build.gradle` to use semantic versioning for app version and add commit hash and `github` to APK file names

The `versionName` will now follow semantic version `2.0.0` spec in the format `major.minor.patch(-prerelease)(+buildmetadata)`. This will make versioning the prerelease and github debug builds versions easier and follow a spec. The @termux devs should make sure that when bumping `versionName` in `build.gradle` file and when creating a tag for new releases on github that they include the patch number as well, like `v0.1.0` instead of just `v0.1`. The `build.gradle` file and `attach_debug_apks_to_release` workflow will now validate the version as well and the build/attachment will fail if `versionName` does not follow the spec. https://semver.org/spec/v2.0.0.html

APKs released on github for debug build workflows and releases are now referred as `Github` releases as per termux/termux-app@7b10a35f and termux/termux-app@94e01d68, so APK filenames have been modified to include `github` in the filename. The APKs are still debuggable, so that tag remains too.

For github workflows the apk filename format will be `termux-styling_<current_version>+<last_commit_hash>.github.debug_<arch>.apk`, like `termux-styling_v0.1.0+xxxxxxxx.github.debug_arm64-v8a.apk` and for github releases it will be `termux-styling_<release_version>+github.debug_<arch>.apk`, like `termux-styling_v0.1.0+github.debug_arm64-v8a.apk`. The `last_commit_hash` will be the first `8` characters of the commit hash. The `<last_commit_hash>.github.debug` will act as `buildmetadata` and will not affect versioning precedence.

The dot `.` is used as tags separator instead of dash `-` for `github` release source and `debug` build type in the apk version tag to be consistent with semver build metadata tags. For example `github-debug` will now be `github.debug`. https://semver.org/#spec-item-10

For github workflows triggered by `push` and `pull_request` triggers, `<current_version>+<last_commit_hash>` will be used as new `versionName`, like `v0.1.0+xxxxxxxx`. This will make tracking which build a user is using easier and help in resolving issues as well.

The `app/build.gradle` now also supports following `TERMUX_STYLING_APP_BUILD__` scoped environmental variables.

- `TERMUX_STYLING_APP_BUILD__APP_VERSION_NAME` will be used as `versionName` if its set.
- `TERMUX_STYLING_APP_BUILD__APK_VERSION_TAG` will be used as `termux-styling_<TERMUX_STYLING_APP_BUILD__APK_VERSION_TAG>.apk` if its set.

…of every 2nd month" to `github_action_build` workflow triggers

- `workflow_dispatch` can be used to manually trigger a build, in case action run was deleted or artifacts get expired.
- `cron` is scheduled to be run every 2nd month (`~60` days) because artifacts expire after `90` days by default, and there is no easy way to set `89` days from now/start of year or ideally last commit, and some months have 28 or 31 days, which would make it even harder. Additionally, workflow should get triggered based on `cron` schedule regardless of last push time, so multiple action runs may exist for every commit anyways, so using 2nd month shouldn't be an issue.
- `cron` is scheduled to be run on the 15th minute to reduce chances of workflow getting dropped. If it does get dropped, then `workflow_dispatch` can be used.
  > The schedule event can be delayed during periods of high loads of GitHub Actions workflow runs. High load times include the start of every hour. If the load is sufficiently high enough, some queued jobs may be dropped. To decrease the chance of delay, schedule your workflow to run at a different time of the hour.
  - https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#schedule