bug in limit checks and threads

[Matthew Fluet]

> 1. Save the bytesRequested as part of the gc state and have the gc check it
>    upon resumption.
> 2. Have the LimitCheck code include a loop that checks again, upon return from
>    the GC.
> 3. Have some global max over all (fixed-size) limit checks that the GC
>    guarantees is available upon thread resumption.  Disallow thread switches
>    at variable-sized limit check points.

It would seem to me that 1 is the easiest, but it does seem like a bit of
a hack for bytesRequested to get stuck in with the gcState.

Some combination of 2&3 might work.  Actually, I was thinking more that
only let a thread switch occur at a limitCheck that is generated at a
block header (i.e., don't allow the thread switches to occur at an
ArrayAllocate style limitCheck).  I think that all of the block header
limit checks are constant size, but some of the ArrayAllocate ones might
also be constant size.

Anyways, the motivation was the fact that such limit checks always have a
label associated with them, the label for the block, so we don't have to
invent a label for the limit check.  

I also thought that maybe we could get away with making the block label be
the return label for the invokeRuntime that corresponds to such
limitChecks, but we need to do the stack push on return.