Embryo of debugger stepping over bytecodes
Forgot to increment TOTAL_PRIMES
Debugger stepping [very early work].

In the meantime, I think I screwed meme_tr.g, as compiling idez.mm went
from 30s (master version) to 9min!
Debugger: step into
Debugger: step into and step over
Debugger: step into/over/over_line/out
Fixed parameter storage order on ep
Debugger: stack combo widget
Fix: local f() has procedence over module f()
Debugger: stepping through closures
Debugger: doIt/printIt on current frame
New frame layout and rm [PUSH/POP]_PARAM opcodes

Reworked frame scheme to make it easier to implement "eval on frame" on
debugger. Now, a closure "env" has the same layout as a stack
frame. Then, on entering a closure, we just reassign FP, instead of
ignoring its data and using EP with a different layout and requiring
different opcodes (PUSH_ENV/POP_ENV).

Before, when "eval on frame" where the CP is not a closure or a function
that has a closure, we were screwed, because all bytecodes of that
function were PUSH/POP LOCAL or PARAM, which in turn would force the
eval'd code to use these opcodes -- and if the eval'd code contained a
closure itself...that's when we were screwed (eg, it would either: use
PUSH/POP LOCAL/PARAM to access the CP function's data, and be unable to
close over the env and be returned to other context, maintaining a
reference to the data, or it would force CP to be recompiled to use an
env and ENV opcodes).

Now, all we need to do on "eval on frame" with a CP that is not a
closure or function containing a closure, is to create a heap-fp storage
for locals and params, copy the data to this place, set it as FP, and
assign it to the function's env slot. Voilà.
Debugger: proper eval on frame with the new style of frame layout