Figure out what to do with saften

[alaviss]

From https://github.com/disruptek/cps/issues/76#issuecomment-829725549

We have similar behavior in several places and the "solution" we use thus far -- staggered inclusion in the stack -- is a hack that seems unlikely to weather extension.

We should probably just enumerate the different modes and add proper support into Scope.

But we should talk about whether we even want saften to work this way at all; it's vestigial at this point. I think it might make more sense (read: easier to test and debug) to process the input in passes instead of mixing these stages all at once.

However, it's not obvious: if we switch to stages, we may be moving a lot of the complexity into the type construction. Maybe those artifacts are simply accumulated across passes, I dunno.

Issues that I know of with the current saften:

• Doesn't follow scopes properly,
• Full of returns, basically a bunch of mini rewrite procs.

A few obvious things to do first (doesn't have to be in this order):

• Write more tests, saften got to this point is due to the lack of tests, where fixing one bug breaks an another thing. I got a bunch of failing tests as refactoring prep #81 queued for this.
• Integrate @saem's propertytest to test for cases that we haven't imagined yet, also to verify the properties of saften transformation.
• ✂️ saften logic into smaller procs.

@disruptek suggested rewriting the current iterative approach into multiple passes, but I haven't got a firm gasp on how the transformation is done to draw out a plan, help on this is very welcome :)

[alaviss]

• ✂️ saften logic into smaller procs.

I figured out that this is not easily done at all. A lot of saften logic revolves around cutting the AST and the unfortunate result is that cutting the AST requires interaction with saften's loop. Any form of cutting results in procs that looks no better than being inlined within saften itself.

rewriting the current iterative approach into multiple passes

After some discussions we come to a conclusion of moving the rewrites into:

• Smaller macros/annotations that define scopes, jumps and the transition between them, of which a draft can be seen here. The idea of this is that we use the AST itself to store our scoping data, freeing CPS from keeping this information (which it gets wrong quite a lot at the moment).
• Separate macro passes that perform rewrites, floating, etc.

A proof-of-concept for this can be found at #85