Refactoring IfTrue*Nodes to allow direct execution after specialization

Signed-off-by: Stefan Marr <git@stefan-marr.de>
Make sure the method body expression is adopted properly

Signed-off-by: Stefan Marr <git@stefan-marr.de>
Make sure that always the latest expression is used in the iteration

- not sure what the definition of the for loop is, so, we will write it out explicitly

[TODO-REPORT: mention that such iterations might interfere with the specialization of nodes]

Signed-off-by: Stefan Marr <git@stefan-marr.de>
Refactor exception throwing, need to put it on a slow-path.

The latest version of Truffle complains about String operations being on the fast path. The string creation of the exception message is problematic.

Signed-off-by: Stefan Marr <git@stefan-marr.de>
Change BigInteger creation from using Strings to use a constructor that might reuse BigInteger instances

Not sure what the deal was with this approach to create new BigInteger objects, but it is problematic with Truffle. As far as I can tell, this should still be ok. We don't change the value of any BigInteger instance. So, reuse should not really be a problem, I think…

[POTENTIALLY-PROBLEMATIC]

Signed-off-by: Stefan Marr <git@stefan-marr.de>
Made specialization of MessageNodes safe for recursion

Evaluation of receiver or argument expressions can lead to specialization of the AST while the uninitialized node is still on the stack, and will later continue execution and try to specialize the node as well.
An example program is Queens.som:49.

[TODO-REPORT: specialization of nodes needs to made be safe to handle the situation that an uninitialized node remains on the stack and will try to specialize the same node more than ones]

Signed-off-by: Stefan Marr <git@stefan-marr.de>