Add some CI fixes

[finagolfin]

No description provided.

[finagolfin]

Now that 6.1 branched, I had the CI build the first Android SDK bundle from the first tag from that branch today.

It passed all CI testing, but if you want to test it with other packages of your own, @marcprux, try it out. You will probably have to pass SwiftPM the additional flags -Xswiftc -disallow-use-new-driver like on this CI though.

[finagolfin]

I want to look into consolidating the number of jobs next, way too many right now.

[finagolfin]

@marcprux, let me know what you think of this consolidation of CI jobs, which allows me to package the SDK bundle much earlier and eliminate a bunch of logic. There is some new repitition because build-script and swift build don't currently support building for multiple Android targets from one invocation, but the plan is to update those tools to support that. Also, the SDK for each arch is no longer built in parallel on multiple CI runners, so that takes longer, but I'm fine with it.

[marcprux]

let me know what you think of this consolidation of CI jobs

I had been looking over it earlier, and I like it. I think building the sample repositories using the post-packaged and installed SDK is a great idea, and I doubt we will see it take much longer from the lack of parallelization.

Personally, I think that we might also want to ditch the macOS jobs altogether. We're a long way from getting the SDK to actually build on macOS (I've given up trying to work around all the Darwin assumptions in the build scripts), so the current behavior of just downloading the cached Linux build isn't all that useful (and requires re-running the failed CI job every time there's a new Swift nightly release so macOS can find the Linux-cached build). Not testing on macOS would be a bit of a loss, but I done recall ever seeing test fail on the macOS Android emulator that otherwise passed on Linux Android emulator, so I don't see any loss of coverage there.

Such a change doesn't need to necessarily be done as part of this PR, but it would contribute towards the simplification and speeding up of the process.

[finagolfin]

I agree that the macOS jobs don't currently add much, but I like having them double-check that the SDK bundles built on linux are working well to cross-compile packages. I plan to look into building the SDK bundles also on macOS in the coming months.

[marcprux]

Sounds good. An alternative solution could be to break it up into two separate jobs, a build-and-cache-sdk job that just runs on Linux, followed by a dependent install-sdk-and-run-tests job that runs on both Linux and macOS. This would be 9 jobs (3 Linux builds + 3 Linux tests + 3 macOS tests) instead of your proposed 6, but still better than the current 15 jobs, and wouldn't require manually re-running the failed macOS build whenever there's a new Swift nightly release and it misses the cache.

[finagolfin]

I thought about keeping a seventh initial job, simply to download and cache the toolchains and turn off the mac jobs if a new snapshot is tagged, as done now. I'd rather just restart the mac jobs instead, at least until I get them building SDK bundles too.