Switch our Python set implementation to use a llvm::DenseSet

Microoptimize the rewriter class

Improve the float implementation, enable test_float

make `int("some_random_string")` faster

Probably more compatible, but also much faster.

Also, set str_cls->tp_repr.

We currently over-build it quite a bit; I'll try to look into that
issue, but for now we can lessen the effects by at least building
it in parallel.

Allow string + bytearray => bytearray. Fixes #780

improve getattr() speed

We're keeping them around anyway

Our exception throwing is still slower than CPython's, and it looks
like it's partially due to the CAPI calls we do as part of the throwing
process.  For example, we have to actually create an exception object,
which involves calling the exception type constructor, etc.  We could
try to jit this stuff, but for now add another fast-path to typeCall
that should catch some of this.

Also, add a fast-path that inlines most of the exception-creation behavior.
Looks like this isn't too much faster than the above-mentioned fast-path.

Remove __attribute__((__malloc__)) from the gc

support yield statements inside lambdas

This attribute unfortunately lets the compiler skip stores if
the pointer doesn't escape.  This is bad because we will be
looking at the memory during a collection; the compiler was skipping
storing to cls and then the gc was crashing.

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.