CLONE -Threads created for Fibers/Generators/Enumerator.next must die due to GC and raise a nice error when threads are unavailable

This is a clone of the previous bug (JRUBY-3964) to address a few additional points that were not critical enough for 1.4:

• When Enumerator thread creation gets ahead of GC for dead enumerators+threads, we must have a mechanism for choking the rate of creation of new enumerator threads. My proposed way would be to use a weak reference queue to actively tidy up old enumerators+threads in the logic to create a new one; this will slow down creation to the speed at which GCable threads can be cleaned up.
• When we reach a thread limit, we need to raise a nicer error. Right now the Java OOM error percolates out, killing the thread calling #next

FYI, also needed for this bug: get Fibers to GC like 1.8.7 generators are (from the previous bug). I will update description to reflect the actual tasks.

Moving to 1.6; there will be no additional work on Ruby 1.9 Fibers in this cycle.

I checked a few scenarios:

• Construct fiber, never resume it - ok; the fibers get collected before being fed into the executor, and so there's nothing to leak.
• Construct fiber, run to completion - ok; fibers finish executing and get collected
• Construct fiber, start it, but it does not complete - LEAKS; the fibers are kept alive by the executor thread

I started playing with some improvements to make the Fiber instance be GCable, but could not get it to shut down the thread. This is a fairly big deal if people are expecting to leave Fiber instances lying around, but if they are running them to completion they should be ok. I'm going to punt this to 1.6.1 since most changes I could make now would need more bake time than RC2 could provide.