Run iOS build in CI

[gnprice]

Similar to #772, but for flutter build ipa instead of flutter build apk.

I don't think we've yet had any problems that this would have caught, unlike the Android case, but clearly in principle it can happen for the same kinds of reasons. It is somewhat less likely, though, because we currently write much less code of our own on the native iOS side than the native Android side.

This might be more annoying to do than the Android, because Apple's developer tools are often harder to wrangle. Or it might not be; we'll find out.

Given the costs and benefits, probably the right approach is:

• Let's spend a small amount of time — like no more than a couple of hours' work — exploring this in the near term, while the question is fresh in mind. Try to see if we can easily arrange in GitHub Actions to have a working flutter build ipa as part of our CI, and without it making our CI runs take vastly longer.
• If that small amount of time doesn't lead to success, then leave this issue open and move it to a later milestone.

[gnprice]

Here's an example where a version of this would have been useful — a deps upgrade broke the iOS build:
#1117 (comment)

There is a wrinkle, though: when I try flutter build ipa at the same commit, it actually succeeds. Meanwhile flutter run targeting an iOS device fails. So ideally we'd either include flutter run in CI, or find some other command that reproduces that PR's build failure and include that in CI.

update: Well, that failure went away after flutter clean. So that makes it less useful to catch, and also means CI likely wouldn't have caught it anyway.

[gnprice]

Moved this to a nearer milestone: the iOS build will become more interesting soon with #1379 introducing some nontrivial Swift code, and that increases the value of having it in CI (as @rajveermalviya points out at #1444 (comment)).

If we further add a check that none of the files in the repo got modified, then that will also help catch side effects that should be included in an upgrade commit (as also pointed out in #1444 (comment)).