Have pypa parse strings directly

Save the key hash in dictionaries

Enable libpypa support for break/continue misuse detection

Introduction of slice ast type & updated libpypa

This lets us avoid checking equality if the hash values didn't match.
Checking equality can involve calling into user code, so it can be both
a perf drain and a noticeable behavioral difference.

Previously we would always write out the data to a file, and then
call the parser on it.

Most of this is refactoring to split the file-handling logic (ie reading
from a FILE*) from stream-handling logic (encoding, counting line numbers,
etc).  One tricky point is handling encoding markers inside strings-to-
parse; we (and CPython) handle the file case by creating a Python file
object to iterate over it, and CPython handles the string case with a special
function to pre-process and decode the string.  This commit takes the
approach of creating a cStringIO file-like-object and running it through
the same decoding logic as the file case.

Change isSubclass(obj->cls, int_cls) to PyInt_Check

ie everything that the linter was warning about

First job: check for cases where we call isSubclass() when it would
be faster to call Py*_Check

Probably overkill for this.  Pretty cool though that it found a
case that would have been impossible to spot textually, where there
was an implicit this-> member access.

More small optimizations

Some work on the NumPy test

Improve dictionary performance

Get Pyston building on Fedora

Previously it would have to call out to checkAndThrowCAPIException(),
which is quite a bit slower than what it now can do, which is directly
checking the return value.

Previously, we would just call these "conservative python" objects,
and scan their memory conservatively.  The problem with this is that
the builtin type might have defined a custom GC handler that needs to
be called in addition to the conservative scanning (ie it stores GC
pointers out-of-band that are not discoverable via other gc pointers).

We had dealt with these kinds of issues before which is why I added
the "conservative python kind", but I think the real solution here is
to say that to the GC, these objects are just python objects, and
then let the type machinery decide how to scan the objects, including
how to handle the inheritance rules.  We were already putting
"conservativeGCHandler" as the gc_handler on these conservative types,
so let's use it.

Refactors on types of GC objects

Instead of GCKind::HIDDEN_CLASS, use GCKind::RUNTIME and require that
the runtime objects have a gc_visit functions by inheriting from
GCAllocatedRuntime.

Those should never exist because all Python objects should be created
through the CPython API except for type objects. Unfortunately, some
places like NumPy do that so we need a mean of patching it for now.

C extensions (NumPy) might inherit classes in C code and expect to find
tp_number. This is just copied from CPython's PyType_Ready.

This requires assigning some of the runtime functions to thesq_ and mp_ slots
otherwise there are infinite loops from Pyston attributes.

NumPy is huge, bigger than our previous (arbitrary) number by an order
of magnitude.

rewrite float comparison base on CPython implementation

microoptimizations