Add IO.popen spec for when child has exited and has been waited for

Extract from the Puma specs
When closing a popen pipe, child might already have exited

In the Puma tests a server is spawned with IO.popen and in the teardown
it explicitly uses a waitpid() when shutting down. This means when
IO#close tries to do that too, it throws an error.

In this case, we can ignore the error if the child has already
disappeared.
Teach the JIT about fixnum_div and fixnum_mod

The JIT now knows about these primitives. We only have an optimized
version for the case where both arguments are non negative, where the
semantics of division are the same for C / machine code and Ruby.

Benchmarks

Before:

=== bin/rbx ===
Fixnum / Fixnum => Fixnum
                     20107655.8 (±2.8%) i/s -  100587036 in   5.006519s (cycle=201982)
Fixnum / Bignum => Fixnum
                      3162968.2 (±1.8%) i/s -   15852256 in   5.013464s (cycle=141538)
Fixnum / Float => Float
                       717959.5 (±1.7%) i/s -    3632104 in   5.060508s (cycle=45976)

=== bin/rbx ===
Fixnum % Fixnum => Fixnum
                    18813711.0 (±1.9%) i/s -   94043780 in   5.000567s (cycle=204443)
Fixnum % Bignum => Fixnum
                     2717041.6 (±2.0%) i/s -   13695336 in   5.042541s (cycle=134268)
Fixnum % Float => Float
                    12421966.6 (±2.4%) i/s -   62129025 in   5.004790s (cycle=276129)

After:

=== bin/rbx ===
Fixnum / Fixnum => Fixnum
                     28664392.0 (±7.0%) i/s -  142374720 in   4.998395s (cycle=220736)
Fixnum / Bignum => Fixnum
                      3072905.7 (±2.2%) i/s -   15458226 in   5.032969s (cycle=157737)
Fixnum / Float => Float
                       730467.0 (±3.4%) i/s -    3682348 in   5.047618s (cycle=46612)

=== bin/rbx ===
Fixnum % Fixnum => Fixnum
                    29326307.6 (±3.5%) i/s -  146445445 in   5.000831s (cycle=208315)
Fixnum % Bignum => Fixnum
                     2667568.3 (±1.9%) i/s -   13332110 in   4.999839s (cycle=140338)
Fixnum % Float => Float
                    13014242.1 (±3.4%) i/s -   65100113 in   5.009206s (cycle=259363)
Improve performance of Fixnum / Float case

The slowness of this case really showed in the benchmarks of the
previous commit. This change improves it a lot.

Benchmarks

Before:

=== bin/rbx ===
Fixnum / Fixnum => Fixnum
                     29537345.3 (±4.6%) i/s -  147317067 in   5.000582s (cycle=207197)
Fixnum / Bignum => Fixnum
                      3047918.1 (±4.3%) i/s -   15215079 in   5.001627s (cycle=163603)
Fixnum / Float => Float
                       718033.1 (±1.2%) i/s -    3613038 in   5.032528s (cycle=46321)

After:

=== bin/rbx ===
Fixnum / Fixnum => Fixnum
                     29195695.3 (±3.6%) i/s -  145885818 in   5.003754s (cycle=223067)
Fixnum / Bignum => Fixnum
                      3114276.4 (±3.4%) i/s -   15702263 in   5.048494s (cycle=161879)
Fixnum / Float => Float
                     15513110.3 (±2.9%) i/s -   77558080 in   5.003963s (cycle=285140)
Specs for Marshal.dump(Float).
Fixed Marshal.dump with Float on 1.9. Fixes 2068.
Specs for Marshal.load with Float.
Remove Array#indexes, Array#indices on X19

These methods are deprecated on X18.
And removed from Ruby 1.9~.
(Specs are already described.)
Merge pull request #2069 from kachick/fix/remove_Array-indexes,indices_on_X19

Remove Array#indexes, Array#indices on X19
Adjust blank line to improve coding style in a spec file
Add spec for Array#index, Array#find_index

ported from rindex_spec.rb
Fix Array#find_index

Array#find_index is currently calling Enumerable#find_index so directly.

Example

    Array.instance_methods(false).map(&:to_sym).include? :find_index

Return value of MRI

    true

Return value of Rubinius

    false
Fix Array#index

It should return {Enumerable::}Enumerator when no argument/block given.

MRI

    [1].index #=> a instance of Enumerator

Rubinius

    [1].index #=> LocalJumpError: no block given
Merge pull request #2063 from kachick/fix/Array-index,Array-find_index

Array#index, Array#find_index returns Enumerator
Add FFI::Platform.windows?
Add FFI::Platform.windows? spec
Add FFI::Platform specs
Fix the it labels for FFI::Platform specs (darwin)
Fix signing issue with Fixnums in the JIT

Previously we were using LLVM's lshr instruction, which is defined as:

The 'lshr' instruction (logical shift right) returns the first operand
shifted to the right a specified number of bits with zero fill.

This means it doesn't consider the sign bit. This means that parts in
the JIT that were using this, could cause wrong numbers to be created if
a negative fixnum was shifted so it could be used as a normal number.

Therefore we need to switch to using 'ashr', which does consider the
sign bit:

The 'ashr' instruction (arithmetic shift right) returns the first
operand shifted to the right a specified number of bits with sign
extension.

This change however, exposed another issue. In the tuple handling we
checked whether a fixnum was not too big for the tuple, but not whether
it was positive. This was not a problem before because of the signedness
issue, it would end up as a very big number that was outside the tuple
anyway. Because of switching to 'ashr', we need a better check.

For these better checks we create some helpers, because the check
whether a number of two numbers are positive are needed in a few more
places, such as fixnum_div and fixnum_mod. Using these helpers also
cleans up the code there.
Use regular additions for Fixnum addition and subtraction

Previously we used 63 bit computation with overflows. This however as
slightly different semantics than our Fixnum, because our Fixnum::MIN is
not the same. This would mean that in the JIT a value of Fixnum::MIN - 1
would come out as a fixnum.

Since for multiplication we need these checks anyway, since in LLVM 3.0
i63 with overflow multiplication is broken, we reuse this code for the
addition and subtraction case here. We also immediately promote to
bignum now if it doesn't fit so we don't recompute the value in the
send. This provides a small performance improvement for the case where
Fixnum +/- Fixnum results in a Bignum:

Before:
Fixnum - Fixnum => Bignum
                      6590050.7 (±12.2%) i/s -   32387040 in   5.009288s (cycle=192780)

After:
Fixnum - Fixnum => Bignum
                      6963561.3 (±4.7%) i/s -   34828744 in   5.015573s (cycle=192424)