Fixed premature evaluation of if condition (Closes: #20).

Condition was being evaluated twice on if+else expression: expr:cond in
"if" production evaluates it but fails to parse remaining ast (because
of lack of "else"), then the next production "if/else" evaluates
expr:cond again.
A very..VERY ugly and fragile fix (?) for issue #18.

The problem at hand seems related to event looping. As far as I
diagnosed, there is a QApplication loop (for the main process) and,
nested, a QEventLoop loop (for the debugger process). During the back
and forth of steping between greenlet processes, there was no memetalk
code to step into anymore, and execution was going back to C++/Qt at the
end of the callback that executes the "doit", which means we are getting
back to the internal loop. The crash happened, I think, because the
process stack executing is that of the QApplication, thus, qapp's loop
resumes, not qeventloop's one; then, some assertion may have caugh this
an decided to bail.

So, the challenge was to identify, before going back to c++/Qt loop,
which loop is the most nested one, 'cause we should get back to it
(meaning, we should switch to the process whose stack is executing that
loop).

For now, instead of just switching the process back (which, in practice,
meant that the main process got back to executing normaly its c++ loop
and the debugger stood there debugging squat), I'm doing some shitty
back and forth to signal the debugger that it should terminate its event
loop and close its UI. Afterwards, the reference to the debugging
process is nullified, and the state of the main process becomes
'running' -- maybe it should remain 'paused', but anyway.

One thing to notice: because we are tree walking, there is a
correspondence between the python stack and memetalk stack. As soon as
we require two independent execution lines (say, for executing a
debugger), we *do* require a concurrency mechanism which provides full
distinct stacks for the different execution lines -- this explains why a
single line approach is out of question.

Closes #18 (hopefully)