Support codegen for closure bindings

[j-hui]

This PR adds support for the new closure bindings supported by our runtime library.

A few expected changes:

• Standardize the C function call interface (analogous to ABI), such that all step functions have the type:

  ssm_act *(*)(ssm_act_t *parent,
             ssm_priority_t prio,
             ssm_depth_t depth,
             ssm_value_t *argv,
             ssm_value_t *ret)

  Regression test harness is adjusted to accommodate this change.

• Mangle enter and step functions with underscore prefix (i.e., __enter_ and __step_), toward more standardized mangling behavior.
• Use ssm_closure_apply at every application, and check for yield after each application. Further optimization here to be explored in the future. (Application for data constructors remain the same.)
• Produce value pointing to closure when referencing a function name.

And two changes perhaps warrant some discussion:

1. (!!) Generate static closure for each global function, so that we don't have to allocate a dynamic closure for each such reference.

   I chose to do this because the alternatives are more complicated; dynamically allocating closures for top-level functions requires us to start tracking their lifetimes, which we don't yet have the capability for, while directly inlining call to the enter function begins to encroach upon optimization, which I don't want to tackle yet (and shouldn't do in codegen anyway).

2. (!!) In the codegen phase, side-effectful expressions (other than function calls) are now forbidden as par operands.

   I realized while working on this PR that our old compilation scheme was wrong. Say e1, e2, and e3 are all side-effectful functions; given par { e1 () | e2 (e3 ()) }, one would expect the effects of e1 to take place before e2 and e3. However, the old compilation scheme would first evaluate e3 () to produce the argument for e2, before yielding to e1 and e2, meaning we would observe e3's effects first.

   Such parallel effects should be abstracted out in an earlier compiler phase, so that the order of effects obey what we would expect of par expressions. So in codegen, I require that all operand expressions of a par expression be pure and "simple".

I'm open to suggestions for how to better address two of these issues, especially 1, though my current plan is to just push on ahead and refactor later if we find that either of these choices lead to issues.

[j-hui]

wtf why did it fail earlier

i swear i tested this locally

[j-hui]

also why was the build cache invalidated

i have questions.

[j-hui]

Still no clue why the build is taking so damn long but at least tests are passing now.

I wrote one test, closures.ssl, that is essentially the same as the example I wrote in ssm-runtime. I'll probably write a couple more tests, i.e., I want to get map working. I'm also going to attempt some lambdas and see if @hmontero1205 's closure conversion works as advertised (!!).

[j-hui]

Thanks for the review @EmilySillars !

does SSLANG support pattern matching on closures/is pattern matching for closures supported in this PR?

no, that's not possible (in general, one cannot pattern-match on any function type).

I think the way closure tag fields are constructed and the way pattern matching works currently will cause problems for representing fully applied ADTs as closures down the line. This is an issue for the future though.

In your example, the closure will be evaluated (i.e., reduced) to a value of value of type Shape before being scrutinized. So that should be ok.