Editable typedefs stage 1

[georgefst]

Closes #267. Although I've edited the "future work" section there, to draw attention to some limitations which were implicit in the original spec, and became clear during implementation.

There is one part of the spec which we don't implement here: it says that we don't add unnecessary holes - see e.g. "when the program does not otherwise typecheck". But in this PR, we are cautious and always add holes where they may be needed, without examining the wider context. Some discussion is still needed around implementating this. The simplest approach seems to be to add the hole, then try to clean up by running the typechecker with smart holes enabled (this is a bit of a sledgehammer, and we might be able to improve performance with a cleverer approach, but I think we already do similar elsewhere). There's a WIP at https://github.com/hackworthltd/primer/tree/georgefst/editable-typedefs-1-smartholes. The implementation might not need to be very complex, but there's no real harm in splitting it out in to a follow-up PR - the work in this one has already been in flight for long enough, without adding anything else.

There are some decisions about name clashing to be tackled as part of #359, #332 etc. For now, we check the minimum e.g. that type names don't clash with each other.

Note that there are some fairly (but not completely) tangential drive-by refactors in the first few commits. I could split the main "Add actions for incrementally editing type definitions" commit up more (i.e. one commit for each new action), but it just doesn't seem like a great use of time after the fact - it would mostly be a lot of busywork with fiddling imports.

Performance could be slightly better in a few places. We have functions like !?, insertAt, adjustAt, etc. which could take constant, rather than linear, time with the right data structures. This is not much of an issue for now as lists will be small in practice, and we have bigger performance issues elsewhere.

[dhess]

(Note: before this can be merged via Mergify, you'll need to mark every conversation as "resolved." We talked about relaxing this recently, and I apologize that I haven't gotten around to it yet.)

edit #387, but let's merge this first.

[georgefst]

(Note: before this can be merged via Mergify, you'll need to mark every conversation as "resolved." We talked about relaxing this recently, and I apologize that I haven't gotten around to it yet.)

Thanks, I had forgotten that. Ordinarily I would have left #367 (comment) and #367 (comment) open, since they aren't so much "resolved" as we've just decided they aren't particularly important.