Fix support for large call stacks and avoid StackOverflowErrors

[fniephaus]

The first attempt to enable large call stacks by catching StackOverflowErrors and throwing process switches does not work in some cases. Maybe we could use https://openjdk.java.net/jeps/270 to ensure a bytecode can be executed until the end (vs. being interrupted in the middle of execution by a StackOverflowError). Otherwise, we probably want to something similar to RSqueak and count stack frames in the interpreter. We can then trigger a process switch after a certain threshold is reached.
AWFY's CD benchmark is highly recursive and currently fails because of StackOverflowErrors, but we will be able to use it to measure the performance of our implementation.

[johenning]

Simple test for StackOverflowError: 1500 factorial

[johenning]

With c6bbb2d factorial works up to ~45000. From there on up it crashes with:
Uncaught exception at ..\..\src\share\vm\jvmci\jvmciRuntime.cpp:1488 java.lang.StackOverflowError

[fniephaus]

With fd65b19, factorial works for even higher numbers than 45000 and even the CD benchmark runs (still pretty slow though). It looks like maintaining the stack depth counter in compiled code is not too expensive, but avoids StackOverflowErrors which can apparently happen in compiled code as well.

[fniephaus]

Turns out there was a bug in the Smalltalk port of the CD benchmark that caused excessive stack depths (see smarr/are-we-fast-yet#69). The fixed CD benchmark runs fine on TruffleSqueak, so this can be closed for now.