popen3 handling for a two-element array at the beginning of the arg list.

This should fix Open3.popen3 in 1.8 mode.
Fix Open3.popen3 for the multiple-arg case with a leading array also.

Refactored this fix a bit for readability.
JRUBY-6679 count in windows console code page
spec for JRUBY-6679
pass for most western codepage
HEADS UP!  Removed all trace of setWithinDefined and isWithinDefined.

* Tested on rubyspecs in 1.8 and 1.9 mode -- AST, JIT, IR.  No
  change in failures after this change.

* Removed this from AST interpreter, JIT, IR

* setWithinDefined was set by all of these before entering defined?
  checks and cleared on exit.  isWithinDefined was only used by
  RaiseException to decide whether to set $! or not -- effectively
  $! was not being set for exceptions raised by code executing
  by the call tree rooted in the defined? checks.  However, this
  resulted in buggy behavior because this call tree could do a ton
  of work (including loading files, requires, setting up classes,
  etc.) any of which can raise exceptions and might have to be
  handled, which require access to $!.  The workaround in IR and
  AST interpreters was to set "$!" whenever an exception was
  received (effectively bypassing the condition that RaiseException
  was guarding).  But, since I removed both these hacky checks as
  part of a previous commit (20632af6e1fa511fd9b762beda2a60d39bf3c859),
  we had code failures in Rails (bug JRUBY-6705) because of files
  not getting loaded properly. So, given that isWithinDefined is only
  used by RaiseException, which was anyway getting bypassed, there is
  no reason to keep that check around.  Once I removed that check,
  since there was no other use of isWithinDefined in the codebase,
  I also removed setWithinDefined, which led to a bunch of dead code
  which I purged.

* NOTE: JIT is probably yet to remove the $! hack that I removed in
  the other commit.  It would be best to remove that hack as well
  so we know for sure that these two commits are working together
  well without bugs.
Merge remote-tracking branch 'origin'
Move Avi's benchmark to a simpler name.
Fix for JRUBY-6728. This fixes Nokogiri's 1.9 test error of PrettyPrint as well as https://github.com/sparklemotion/nokogiri/issues/657.

The change didn't break test:mri19. However, oddly, test_condvar_wait_exception_handling of test/externals/ruby1.9/ruby/test_thread.rb has become failing often  on my macbook. But, not always. This change might have revealed threadding issue?
Fix JRUBY-6740

BasicObject.respond_to? raises a "undefined method `respond_to_missing?'"

The caching logic for respond_to? was unconditionally calling
respond_to_missing? even for custom respond_to? methods. It should
only be calling it for the builtin respond_to? logic. However, in
order to make it work properly, respond_to_missing? logic would
need to be added to the caching logic, meaning we would need to
additionally check whether respond_to_missing? was also builtin
and invalidate appropriately. Due to the complexity of adding
another dimension to respond_to? caching, I'm just disabling the
caching logic altogether for 1.9 mode and have filed JRUBY-6749
to track us getting it reenabled.

FWIW, indy dispatch does not do any respond_to? caching for either
1.8 or 1.9 mode, and was unaffected by this bug.
Guard 1.9-only regression spec against 1.8 mode.
Added fix for Thread list race condition

Signed-off-by: Charles Oliver Nutter <headius@headius.com>

For JRUBY-6748.
Merge branch 'master' of git://github.com/jruby/jruby into beaver
Update to latest MRI flags and use hex for fun and profit
Regression spec for JRUBY-6748.
Fix JRUBY-6745

ClassCastException calling Fixnum#== with a Java Integer

The problem here was that when given multiple overloads that are
all dispatchable with a given set of arguments, we just picked the
first one. This specific case had both compareTo(Object) and
compareTo(Integer), and we picked the Object version. Because the
coercion from Fixnum to Object produces a Long, we eventually hit
a ClassCastException when the Object version tried to call the
Integer version. By fixing Java method dispatch to narrow
overloads to the most specific version, we now will call the
Integer version and coerce properly.

I believe this was working in 1.6.7 because we had other bugs
relating to how we coerce versus how we dispatch that caused us
to coerce to Integer but still call the Object version.
Fix JRUBY-6740

BasicObject.respond_to? raises a "undefined method `respond_to_missing?'"

The caching logic for respond_to? was unconditionally calling
respond_to_missing? even for custom respond_to? methods. It should
only be calling it for the builtin respond_to? logic. However, in
order to make it work properly, respond_to_missing? logic would
need to be added to the caching logic, meaning we would need to
additionally check whether respond_to_missing? was also builtin
and invalidate appropriately. Due to the complexity of adding
another dimension to respond_to? caching, I'm just disabling the
caching logic altogether for 1.9 mode and have filed JRUBY-6749
to track us getting it reenabled.

FWIW, indy dispatch does not do any respond_to? caching for either
1.8 or 1.9 mode, and was unaffected by this bug.
Guard 1.9-only regression spec against 1.8 mode.
Added fix for Thread list race condition

Signed-off-by: Charles Oliver Nutter <headius@headius.com>

For JRUBY-6748.
Remove swp file that snuck in.