Correct FNAME/ENDFN issue fname never transitions to endfn
Updated the version to 1.7.11 in pom.rb to get a test in test/test_env.rb to pass.
test/test_env.rb: Changed it to use a different ENV variable because ENV['TEST'] is used to tell the Rakefile which test files you want to run.  This change allows you to run 'TEST=test/test_env.rb rake test:jruby' in order to just run the tests in test_env.rb.
Partial fix for #1463.

In order to make a Thread and the fiber it is resuming look like
a single unit, we must make sure that asynchronous exceptions
happening at that boundary propagate the right direction.

Exceptions raised in a thread waiting on Fiber#resume should go
into the fiber and be handled there. Exceptions raised on a fiber
waiting on Fiber.yield should go to the resuming thread and be
handled there. This is done by capturing exceptions in
Fiber#resume, transfer, and yield and propagating them to the
waiting thread/fiber if its queue is still active. If that queue
is not active (the fiber has exited), the exception is propagated
upward in the current fiber/thread.

The unknown case is what should happen to a fiber in which an
exception (for example, a timeout) has triggered.

In MRI, where there's really only one thread, the timeout would go
to the resuming thread and happen arbitrarily in its running code.
The originating fiber would be left undamaged as if nothing had
happened, and would be subject to GC if abandoned or resumable as
normal. In this patch, the original fiber performs the same
exception-propagation loop and goes back to its queue for a
resumed value; this should roughly match MRI's behavior. However,
I am not sure I agree with MRI's behavior, or if MRI's behavior is
correct, then Timeout should *never* be used around Fiber.yield,
since it is impossible to know where and when it will fire.
Handle uncancellable timeout future more reliably.
Revert "Added new option jruby.timeout.thread.pool.max to control the max number of Timeout worker threads."

This reverts commit 8bbe14b9a3483ff9a789f56cc3a4beeb7446a18e.

The first parameter to newScheduledThreadPool is not a max, it is
a minimum. That makes the original commit moot, since it does not
limit thread count and actually causes more threads to be alive
than are necessary.
Add specs for both cases from #1463.
Merge branch 'jruby-1_7' of github.com:jruby/jruby into david17
Fix some more line number tests.