Fix race when unlocking locks for a thread

The problem was that we unlocked the locks first after the thread was
marked as not alive. This opened a race for seeing a mutex as still
locked after a thread was joined, since that thread was seen as not
alive and not waited for while it was still terminating and unlocking
locks.

This would cause a sporadic spec failure like this:

1)
Mutex#locked? returns the status of the lock FAILED
Expected true to be false
           { } in Object#__script__ at spec/ruby/shared/mutex/locked.rb:31
  BasicObject(Object)#instance_eval at kernel/common/eval19.rb:45
      { } in Enumerable(Array)#all? at kernel/common/enumerable.rb:104
                         Array#each at kernel/bootstrap/array.rb:68
             Enumerable(Array)#all? at kernel/common/enumerable.rb:104
              Integer(Fixnum)#times at kernel/common/integer.rb:83
                         Array#each at kernel/bootstrap/array.rb:68
           { } in Object#__script__ at spec/ruby/core/mutex/locked_spec.rb:5
                  Object#__script__ at spec/ruby/core/mutex/locked_spec.rb:4
                        Kernel.load at kernel/common/kernel.rb:584
  BasicObject(Object)#instance_eval at kernel/common/eval19.rb:45
                         Array#each at kernel/bootstrap/array.rb:68
   Rubinius::CodeLoader#load_script at kernel/delta/codeloader.rb:68
   Rubinius::CodeLoader.load_script at kernel/delta/codeloader.rb:111
            Rubinius::Loader#script at kernel/loader.rb:648
              Rubinius::Loader#main at kernel/loader.rb:847

When we move this up we have to do an unlock / lock around it, since
unlock_locks would unlock all objects, also the thread itself, so we
need to lock it again.
Don't unlock thread itself in unlock_locks

This removes the need for the unlock / lock pair in the thread logic.
Create global for encoding list

This way we don't need a symbol lookup inside the path for symbol
lookup. This would cause a deadlock with fixing some SymbolTable locking
issues.
Lock around all symboltable operations

These operations weren't locked around, so it could cause issues when
a thread for example was resizing the backend storage for symbols and
another thread was using lookup_debug_string.

This could for example happen when the JIT was running since that uses
lookup_debug_string. It uses this for the module naming of jitted
 methods. If at that same time symbols were added and a resize
necessary, this could cause invalid memory usage or corruption.
Add Module#const_set specs for frozen module
Fix Module#const_set for frozen module
Add Module#autoload specs for frozen module
Fix {Kernel,Module}.#autoload for frozen module
Module#freeze should freeze `constant_table` as `method_table`
Lock around kind of symbol lookup

Also cleans up symboltable size code. We already track the size anyway
so all places needing the size should just used that.
Set encoding last because it reads ascii_only and valid_encoding

This fixes a jump on uninitialized memory warning in valgrind.
Use primitive for signbit

The FFI approach would lead to Valgrind erroring with jumps on
uninitialized values. This was due to GCC optimizations that would be
done with the signbit macro.

With this approach we don't get these errors and don't have to add the
ffi_util method.
Always initialize value for FFI callbacks
Don't try to remove locked object if list is empty

This can happen when the thread is already in the termination process
and all locks have been cleaned up and only the thread itself is still
locked.
Don't double allocate replacement setup for transcoding

This was causing memory leaks because the memory was allocated again
under the converter_ even when it already was allocated due to a
previous run.
Fixed a bunch of C-API header issues.
Merge pull request #2582 from kachick/set_constant_on_frozen_module

Module#const_set and {Kernel,Module}.#autoload should raise exceptions on frozen module
Fixed staging C-API headers.
Merge remote-tracking branch 'origin/master' into compiler