Enable Travis on branches with a "test-" prefix
Restore hex and random_bytes to SecureRandom 1.8

The refactor which replaced hex and random_bytes with native code
in SecureRandom accidentally left them broken for 1.8.  Restored!
Yielder return value for each_with_object

Make Enumerator#each_with_object return its yielder's value to match MRI
Added a regression test for issue #1446: Line number in runtime warnings is one greater than the actual line number.
Fixed two places where RubyWarnings was printing lineNumber+1 instead of the actual line number.  This fixes issue #1446.
ThreadContext.gatherCallerBacktrace: Got rid of several lines of code that were computing things that were not used.
Merge pull request #1436 from dmarcotte/travis-on-branches

Allow Travis on select branches
Merge pull request #1439 from dmarcotte/securerand-18

Restore hex and random_bytes to SecureRandom 1.8 (fixes Travis)
Merge pull request #1440 from dmarcotte/enum-ret-vals

Enumerator#each_with_object should provide the yielder's return value to its block
Added multiple implementations of FileResource.

This prepares the transition to using FileResource rather than JRubyFile
directly for any areas where both jars and regular files are to be
supported.
Merge pull request #1450 from DavidEGrayson/warning_line_pull_request

Make warnings show the right line number
Fix Gem.ruby singleton method on Windows
Follow-up to pr #1448 to only use driveletter logic if actually running on windows
Merge big decimal type error fix to 1.7
Fix typo in lexer. lex_state of FNAME should become ENDFN after seeing an identifier
Correct FNAME/ENDFN issue fname never transitions to endfn
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.