Simplify the execution loop and remove wrong assertions

[Jartreg]

This fixes #58.

By simplifying the execution loop, the assertions in exec_step are
no longer required.

The assumption that the current program element has to be done at
the beginning of exec_step is not always true, because breakpoints can change their state between invocations of exec_step. Another possible fix would've been to make the breakpoint's step function return true every time. This could however slow the program down, since exec_step would return for every breakpoint (even deactivated ones).

Note: I might have misunderstood how exec_step is supposed to work, because I'm not entirely sure why it has to return before a step completes.

[TGlas]

The exec_step logic is somewhat complicated, and I am indeed not sure that this is necessary. There is no reason for returning right before a step completes. We could also return right after that, i.e., change the order of trivial and non-trivial steps (means: sim or step returning false/true). The point is that exactly one non-trivial step is run, so that stepping mode in the debugger works correctly. The logic evolved a bit over time. For example, breakpoints were added quite late. It is well possible that it can be simplified quite a bit.

Could you verify the following:

• Stepping mode in the debugger works (essentially) the same way as it did before, also when evaluating scopes and expressions (say, var x = 4; { { print(2+3*x); } }). Please also keep an eye on the stack and program views.
• A breakpoint on a line stops the program right before the first command starting on that line is executed.
• A breakpoint at the very end of the program (after the last statement) works correctly. This is important because it allows the user to investigate the stack after the last command was executed. Once the program ends, the stack state is gone.

I currently cannot think of anything else that could go wrong.

[Jartreg]

Now we know why: it breaks before completing a step so that it can be inspected in step-debugging!

Example:

var x = 0;
x = 1;

Because the constant 0 is a trivial step, there would be no way to halt after it. The only way to see it changing from 0 to 1 is by stopping before the assigment completes. I added an explanation of this behaviour to the description of exec_step.

I've also tested the cases you listed (that's how I discovered the difference) and everything seems to work as intended.

[TGlas]

Thanks, then let's call it good.