Use a spinlock around variable scope retrieval

This is needed because these scopes might be used in different threads,
the simplest example being the following case:

def foo
  a = 1
  Thread.new do
    p a
  end
end

Here the local a is accessed from a different thread. This presents a
problem with flushing the scope to the heap when the foo method returns.
In that case the locals aren't on the stack anymore, but the other
thread might still read the data from the stack due to a race condition.

New threads isn't the only case where this might happen, it can also be
for example the scope capture with a proc or lambda and passed to
another thread for execution. If that accesses the defining scope, this
presents the same problem.

This fixes one cause of crashes of the reproduction in issue #2339.
Explicitly pass in call_frame for going GC dependent

This ensures we always store the last call_frame here as well for proper
GC.
Grabbing the return value shouldn't clear exception state

This was unconditionally removing the thread state when retrieving this
value, but it only makes sense when the state is either cBreak or
cReturn, since this code is always used on conjunction with
rbx_return_to_here or rbx_break_to_here.

This could cause a bug in the interpreter control logic, since now a
method could have returned a NULL and set the exception state, but this
would clear the exception state. This would result in hitting the
rubinius::bug assertion in the interpreter at instructions.cpp:202,
aborting with the "Control flow error in interpreter" error.

Fixes another bug when I was running the repro from #2339.
Add additional GC debugging that is disabled by default

This is some very basic GC debugging that I've been using. It basically
scans the current call frames after a GC to see if the values referenced
there and on the interpreter scan are updated properly.

This was mainly used to debug world halting issues before, still had it
around and thought it would be useful to add so other can enable this as
well for certain cases. The overhead is fairly minimal, only adding a
small time to GC time and no overhead when not GC'ing.
Use consistent naming in #include directives

We don't prefix includes with vm/ in most places since that's in the
include path, so use these consistent by removing this prefix where it
was still used.
Setup lock around tracking of fiber data for stacks

We now have a specialized finalizer thread that also runs Fiber
finalizers, unlike in the past where the GC would directly clean this
up. This does however introduce a race condition here for the data
structure we use to track the fiber data's.

The finalizer thread and another thread could be adding a new fiber data
and removing it at the same time. This could corrupt the datas_ set of
active fiber data. Therefore we should lock around it.

Also found when running #2339.
Use a locking strategy only when needed.

Since this locking has a significant overhead, we only set it up when
requested. Currently we explicit request this when we start a new thread
for the sending scope and when we create a Proc, since that might be
passed to another thread.