Fix a race condition when going GC dependent

This is a fun one. The problem is here that a thread goes GC dependent.
This means it's going to access GC managed memory etc. and doesn't allow
GC anymore. For this it checks whether it needs to stop or not. If it
doesn't have to stop, it increments the thread count and continues.

What happens here is that when it checks should_stop, the value is still
false. After this check another thread will set thread_stop and check
how much pending threads there are. This happens before the other thread
increases the count, which leads to the thread wanting to GC thinking
it's ok to GC and the other thread thinking it's ok to continue.

This never really shows up normally, because of the timing of course and
the fact that in the next checkpoint the thread that originally
continued now sees a GC is requested and will halt. So the way this bug
shows itself, is usually the following.

When the thread thinks it can continue it will setup a new call frame
and store some references, for example a local. This however means that
when the GC walks the call frames, it might be too late, so this new
call frame isn't actually scanned by the GC. So this means the bug shows
itself as for example a local variable that isn't properly forwarded by
the GC.

This is also the reason that setting the call frame properly was also a
first suspect (and actually there were cases where that logic was
missing), but the deeper issue was also this race condition causing the
problem to occur less often but not entirely disappear with the changes
to the call frames.

Race conditions... When found they seem so obvious, when looking it
takes days...