configure: dup frozen strings from ARGV

Strings being brought in from ARGV are frozen; however, the configure
script expects to be able to modify some of the strings being passed in.
This leads to "can't modify frozen String" exceptions when attempting
to pass certain options, such as --libdir. Duping the strings returns
non-frozen copies.
allow RUBYLIB in build scripts

These checks were added to guard against the case where a user might
have e.g. "lib:test" in their RUBYLIB at build time, which would result
in erraneously loading Rubinius' local `lib/rbconfig.rb` or
`lib/rubygems.rb` instead of ones from MRI that's doing the build.

Since `lib/rbconfig.rb` already has a guard against this, and MRI 1.9+
loads `rubygems.rb` automatically at runtime, tripping over the guard in
`rbconfig.rb` immediately before the RUBYLIB check even happens, the
explicit `ENV["RUBYLIB"]` check is both unnecessary and unwanted since
it prevents valid uses of RUBYLIB.

Reverts af5cae6519169841ca8bc97d7501e2ac707b47d7,
        16d3c35a46455157581188f6766b722c98c659fa

References d4793b518bfd8f6c52553ff5694263c577230359
No need to bundle bundler.
Fix type for value
Improve type handling for locals

If we see multiple code paths that end up setting locals, we can't
assume the type anymore of those paths involve different types.

Fixes #2668
Revert "Remove known type optimization for now"

This reverts commit 342e6c2ff44d3be7f9a6a6005d9cb2f1971d8547.

This bug was also very likely caused by the same issue as #2668
Fix indent in jit_operations.hpp
Create no ops for rb_obj_hide, rb_obj_reveal and rb_str_resurrect

I don't know why exactly they are used, but they seem some kind of MRI
internal. We just ignore them for extensions that use this.
Add additional macro's for extensions
Fix style issue with not using {}
Raise more specific exceptions in case of pipe() and fork() failure

This will give the user a more descriptive error, for example if there
is not enough memory to fork().
Load debugger after rubygems.
Avoid using String#clear in File.expand_path. Fixes #2671.
Return the particular thread for Thread#kill.

This way we could write something like this in one line:

    Thread.new{}.kill.join

This is how MRI behaves:

    $ ruby -ve 'p Thread.new{}.kill'
    ruby 2.0.0p247 (2013-06-27 revision 41674) [x86_64-darwin12.2.1]
    #<Thread:0x007fdb2494a898 run>
Spec for Thread.kill. It should return the thread it is killing.
Merge pull request #2677 from godfat/Thread.kill-returns-the-thread

Return the particular thread for Thread#kill.
Recheck mark stack for objects after scanning fibers

When we scan stuff like finalizers etc. it can happen we end up pushing
a new object into the mark stack due to the write barrier when
a concurrent mature mark phase is also in progress.

By rescanning this as well in the loop we make sure we handle all
objects for which this might happen.
Don't use iterator to walk vector that can grow

Problem here is that walking this mark set can result in new entries
being added. This can happen because the write barrier runs for objects
that are seen and this can add elements.

The new entries added can result in a vector resize and that invalidates
all the iterators. This way we prevent this problem.
Always use a minimal size of 1 for ByteArray even if 0 is requested

Methods that work with ByteArray's usually expect to be able to set
things like the last byte to 0. Especially some of the C-API methods
use that. This prevents issues when something creates a ByteArray
of size 0.

Fixes #2657
Initialize ByteArray with room for 0 bytes