Add debug.rb for compatibility with MRI/JRuby.
Wrap up all access to flag manipulation in methods
Move header modifying methods into oop.cpp
Fix race condition when concurrently reading and modifying header

This fixes a potential number of race conditions. The most problematic
one is the following. If we are in the middle of inflating a header and
concurrently reading another flag there's a potential problem. If we
check the header status first and it's not inflated but then read the
flags after it's inflated, the flags contain bogus information.

We fix this by making sure we always first copy the header, then check
inflation status and return this copy if it is not inflated. This means
that the code can see slightly outdated information, but it can already
handle that properly because this type of race could happen in other
places too.

We also change every modification of changing the flags to be atomic.
This is necessary to prevent certain information from being lost. If we
for example freeze an object while concurrently inflating the header, it
could be that we set the frozen bit in the header after we already
copied the flags into the inflated header. In that case setting the
frozen status would be lost.

This is not a huge problem, but the side effect is more problematic.
Since we reuse the header space as the pointer to the inflated header,
modifying a bit there would mean the inflated header would point at a
totally different inflated header. This would mean the object would
suddenly get a very different status.

These changes are related to issue #1940. In this issue the behavior
exposed itself as follows. The code resulted in a concurrent scenario
where an object header was inflated while concurrently retrieving an
instance variable. Because of this, the returned obj_type was the value
of the bits inside the inflated header pointer:

$2 = {
  <rubinius::ObjectHeader> = {
    header = {
      f = {
        inflated = 1,
        meaning = 0,
        obj_type = 217,
        zone = rubinius::UnspecifiedZone,
        age = 2,
        Forwarded = 1,
        Remember = 1,
        Marked = 1,
        InImmix = 0,
        Pinned = 0,
        Frozen = 0,
        Tainted = 1,
        Untrusted = 0,
        LockContended = 0,
        unused = 0,
        aux_word = 1
      },
      flags64 = 4312680137,
      all_flags = 0x1010e46c9
    },
    klass_ = 0x104a3ff90,
    ivars_ = 0x1a,
    __body__ = {0x0}
  }, <No data fields>}

The value here is obj_type 217, which is actually an invalid value. What
happens because of this is that the code in Object#get_ivar would see
that obj_type. This resulted in it not recognizing it as a packed object
and this not running the proper code to retrieve the instance variable.

This resulted in a nil being returned as the instance variable instead
of the actual instance variable and then resulted in a NoMethodError.
Setup memory barrier when installing handle
Remove saved call frame after possible GC in JIT
Make sure the C-API handles are initialized before setting them
Make sure that we setup a barrier before installing the jitted code

Also make sure we remove the setup call frame at the proper moment.
Move directory parameters evaluation out of option parsing.

Move the logic into #set_filesystem_paths, since there is not
enough information to correctly evaluate the parameters earlier.
Don't modify paths if --preserve-prefix option is used.

All compilation output goes into staging directory in this case. There
is no reason to check if there is some colision with some existing
directories in this case.
Don't crash when no prefix is specified.
Merge pull request #1946 from voxik/fix-preserve-prefix-expansion

Fix --preserve-prefix expansion
Merge pull request #1944 from postmodern/debug

Add debug.rb for compatibility with MRI/JRuby.
Always emit code for pushing a block in the JIT

There are situations where we create incorrect code before this fix.

Imagine the following code:

def x
  y do
    true
  end
end

def y
  z { yield }
end

def z
  yield
end

Now if in this case we decide to compile 'x', we can inline y into x and
z into y. The problem occurs when we try to inline z but we can't due to
it being too complex, or when it blows the inline budget. In that case
the block hasn't been pushed so z will raise a NoJumpError because it
can't find the block.

In the future we need to make the JIT logic here smarter. We need to
keep track of whether we end up using the block in the whole chain down
when we compile a method and if we don't end up using the block, we can
remove the code for pushing it.

Fixes #1940
Fix race condition when shutting down

When we request an auxilary thread to shutdown, maybe another thread is
still waiting to do GC. Therefore we need to guard here so we don't
deadlock when somebody requested a GC but we're also shutting down.

Related to #1952
Fix the specs for rb_enc_associate_index

The index values are only valid if they are also retrieved properly. The
integer values don't cary any meaning themselves and therefore cannot be
used directly in the specs.
Add specs for rb_enc_get_index
rb_enc_get_index returns -1 for the encoding for non symbol immediates
rb_str_new creates ASCII-8BIT strings in 1.9 mode
Add tags for failing C-API specs