Speed up CI builds

[garyp]

Right now it takes way too long to build pbandk, which slows down not only local development but also waiting for pull request checks to pass in CI. For example in this recent run: https://github.com/streem/pbandk/actions/runs/2262406097, we spent:

• 30 minutes building pbandk on Linux
• 30 minutes building pbandk on macOS
• 10 minutes building the conformance test runner on Linux
• 15 minutes building the conformance test runner on macOS

Here are ideas for improving things:

• Setup nightly builds on master to keep the cache up-to-date. GitHub will only use the cache from jobs that ran on master when running jobs against other branches, but it also automatically expires the master cache after 7 days. If we add a nightly build, then it should ensure that we always have a recent cache available even if it's been more than a week since the last commit to master.
• Don't build every target when running PR checks. It's probably fine to build a representative set of targets (jvm, js(IR), iosArm64, linuxX64) when testing PRs. We could skip android, js(LEGACY), and all of the other Kotlin/Native targets and only build them post-merge. Worst case we'll have an obscure failure that is only caught post-merge and we revert the PR.
  • We could also add the ability to test the full set of targets on-demand via a special PR comment.
• Setup a matrix job to build the examples. These don't take very long even right now (only 3-4 mins), but splitting them up into a matrix job would be an easy win to shave off a couple minutes.
• Use https://github.com/gradle/gradle-build-action in the GitHub Actions jobs to get more effective caching of Gradle-related files in Github Actions
• Write a gradle task to build the conformance task runner. That way the task could use gradle's caching and up-to-date mechanisms. This probably won't reduce the build times by much over the manual caching we're using for this job right now. But it would simplify things by moving everything inside gradle. And it would make it much simpler for developers to run the conformance tests manually.
  • This is a useful example of how to download arbitrary zip files using gradle's dependency caching mechanism: https://stackoverflow.com/questions/23023069/gradle-download-and-unzip-file-from-url/34327202#34327202
• Use zig cc to cross compile the macOS conformance test runner from an Ubuntu GitHub Actions runner. The Ubuntu runners are cheaper and faster to provision than the macOS runners. Might not be a huge win, especially if we're effectively caching the built test runner after the above optimization. See https://andrewkelley.me/post/zig-cc-powerful-drop-in-replacement-gcc-clang.html for more details on zig cc.
• Maybe split up gradle build and test tasks into separate jobs to get better parallelism? Or even split up the build/test of each Kotlin target into a separate job? We'd need to measure the gain of the extra parallelism against the startup cost of additional jobs, since each job would have to download the sizeable Github Actions cache separately.