Improve thread debugging information
Update the thread id and lock count after setting inflated header

Before we first were setting the thread id and lock count before
updating the inflated header with the current header word. This results
in actually loosing one count, because the header word still has the old
count, but the passed in count parameter is already increased by one.

This would cause an error for the last recursive unlock if we do
recursive locking so often that we need to inflate the header.
Fix object allocation race condition that could cause immix corruption

The problem here is the following case. When we had to fall back to
immix allocation because the young generation slab allocation fails, we
used the new_object_fast code path that used the allocation spinlock.

When this path was used, it almost always ends up calling
new_object_typed which also locks. Because of this there was a manual
unlock before calling new_object_typed. The bug was that because the
lock was a scope guard, we ended up unlock too often after the
new_object_fast method.

This resulted in the possibility that two threads where allocating
objects in immix which isn't thread safe at this point. This caused
memory locations to be used multiple times for different objects,
causing all kinds of weird errors.

The fix completely removes the new_object_fast code path, because unlike
the name suggests, it doesn't actually have any faster code path than
new_object_typed and ended up calling new_object_typed almost always
anyway. Therefore removing this code path is by far the simplest
solution for the problem.

We also fix inflate_for_handle so it uses the proper inflation lock
instead of using SYNC. The last change to ontology setup is more a
stylistic change because I added a bunch of assertions on object
validity which wanted an object to be valid when for example setting
instance variables.
Encoding converter converting encodings.
Removed CI tags for passing specs.
Clean up Encoding::Converter processing structure memory.
Fixed Encoding ontology.

We are going to use Encoding in 1.8 mode behind the scenes but we
cannot expose the Encoding class under Object because stupid Ruby
code in the wild looks for Encoding to decide whether to use 1.9
language syntax. So initially I moved everything under Rubinius,
but this leads to ugly eg Rubinius::EncodingClass::Encoding::XXX
output for exceptions.

This way, we only expose Encoding under Object if not in 1.8 mode.
Added Encoding::Converter#last_error.
Added Encoding::Converter#primitive_errinfo.
Added Encoding::Converter#finish.
Fixed finding transcoding path.
Add caching and pre-computed Encoding::Converter paths.

It takes a fraction of a second to load a pre-computed association of all
possible conversions from the builtin converters. If other converters are
loaded, the cache will still be used, but cache misses are costly because
an exhaustive search will be performed for any missing and unavailable
conversions. However, the likelihood of those are rare, since they will
raise exceptions.

This caching reduces spec run times by about 50% for encoding specs and
about 10% overall.
Barrage of attacks against the dark lair of String#encode.
Revert "ruby 1.9: File.expand_path returns a string in the default external enconding"

This reverts commit 27e43a671d7ff84f56fcbb9261f38d0e7ab60076.

This is not the correct way to fix the spec failure. Rather than fixing
incorrectly and obscuring the issue by removing the spec tag, we need to
leave the specs failing.

Conflicts:

	kernel/bootstrap/type18.rb
	kernel/bootstrap/type19.rb
Fixed loading encodings in 1.8 mode.
Removed CI tags for passing 2.0 specs.
A few silly fixes for Encoding::Converter.
More Encoding::Converter#primitive_convert specs.
Fixes for Encoding::Converter#primitive_convert.
Fixed bug in String::append primitive.