Use control-flow instead of runtime state for the choice of Or arm.

[eddyb]

These two are isomorphic:

{ code: constant, state: per-arm }
{ code: per-arm, state: constant }

So we should be generating more code instead of trying to keep it all in the state.

EDIT: Heh, I just remembered that we ended up here trying to keep down the number of (old) "labels", long before any of the Rc<Rule> -> ParseLabel or CPS stuff.

---

Only problem is that, currently, the {push,pop}_state machinery enforces that the parallel of the Or happens in its own separate function, and the input range of the whole stack frame can thus be used, as the range of the whole Or rule (guarded by an assert_eq).

So this is blocked on #10 replacing the {push,pop}_state machinery with a proper analysis. (Ideally also being able to understand constant rule lengths)