Change interpreter calling conventions to be more direct

[dolio]

This change set reworks the calling conventions of foreign functions to avoid various encoding methodologies that were just wasting time by causing more passes through the interpreter loop. Instead, the ForeignConvention class has turned into a way of specifying how unison values are parsed into their Haskell equivalents, and each foreign operation is expected to just take a number of unison values that are parsed this way. Similarly, single results are written back directly, rather than encoding them on the stack. The result is that most wrappers are now just trivial (and should be subject to inlining).

One additional thing I did was add support for foreign functions that raise an Exception in the unison sense. The convention for these is that foreign functions return booleans indicating whether the result on the stack is valid or exceptional. In the latter case the stack will have a Failure value, and the interpreter will call the current Exception handler. This means that e.g. the array operations are also just trivial wrappers, and don't need to return their results wrapped in Either.

Haven't gotten to benchmarks yet, but the tests I've run are working (@unison/base tests, unison-runtime tests, transcripts and interpreter-tests). I haven't run any cloud tests; if Cody could arrange for that that'd be helpful.

Also haven't compared performance with any of our benchmarks yet.

Making this draft because it seems to indicate I need to merge in trunk or something.

[ceedubs]

I'll run the cloud integration tests against this today.

[ceedubs]

I haven't reviewed the code, but I have verified that the Unison Cloud test suite passes with this change.

[dolio]

Here are some benchmark numbers:

fib1
186.674µs -> 183.472µs

fib2
2.802898ms -> 2.983028ms

fib3
3.295707ms -> 3.379658ms

Decode Nat
228ns -> 176ns

Generate 100 random numbers
180.031µs -> 188.523µs

List.foldLeft
2.326404ms -> 2.313983ms

Count to 1 million
44.410122ms -> 43.79875ms

Json parsing (per document)
276.48µs -> 263.727µs

Count to N (per element)
110ns -> 110ns

Count to 1000
111.101µs -> 110.738µs

Mutate a Ref 1000 times
163.826µs -> 162.988µs

CAS an IO.ref 1000 times
193.437µs -> 190.413µs

List.range (per element)
232ns -> 241ns

List.range 0 1000
277.155µs -> 307.623µs

Set.fromList (range 0 1000)
1.659985ms -> 1.857961ms

Map.fromList (range 0 1000)
1.128239ms -> 1.10596ms

NatMap.fromList (range 0 1000)
4.12972ms -> 3.531125ms

Map.lookup (1k element map)
1.91µs -> 1.621µs

Map.insert (1k element map)
4.726µs -> 4.822µs

List.at (1k element list)
205ns -> 211ns

Text.split /
48.83µs -> 47.647µs

I think most of them are fake, though, because they don't actually use anything that I changed. The real one is Decode Nat because that is actually a foreign, I think. I think even though the Set and (Nat)Map numbers look like significant differences, they actually aren't, and you can get that amount of difference just between runs.

I also wrote a bubble sort on byte arrays test, and it is about twice as fast on the new branch (that was the sort of builtin I would expect to be most improved).

[dolio]

I think this should be good to go. I fiddled around with inlining/strictness on some of the new stuff related to the sorting test case I wrote, but none of it seemed to make any difference.