And change for loops to instead of calling __hasnext__ directly, to
call objmodel::hasnext() which calls tpp_hasnext.

Things are getting pretty messy, but it's an incremental step towards doing things more
like CPython which should ultimately make things simpler.

The use of the tp_getattro slots (even though they're the CAPI slots) seems to lead to
about a ~7% improvement in interpreter-only speed.

ie if we set __getattribute__ on a superclass, we have to update
tp_getattro on all subclasses.  We've always been broken on this, but
this didn't really matter as much until now since we would internally
check __getattribute__ and not tp_getattro.

tp_subclasses is a list of weakrefs, which means that we need weakref
support before we can start finalizing classes.  which means we have to
add a whole slew of things into the bootstrapping section.

We should probably just do this in a more systematic way, but I'm
not sure what that would be...

This is the analogue of 9f63b62e but for getattr instead of setattr:
previously there was no way to run the default getattr logic, since
getattrInternalGeneral would always check for a custom __getattr__
or __getattribute__.  This meant that object.__getattribute__ was
the same thing as getattr() and that PyObject_GenericGetAttr was the
same as PyObject_GetAttr, which were not correct.

update INSTALLING.md, and libsqlite-dev in cmake section

Add support for unicode literals when using pypa

split the getattr/setattr of softspace into two try blocks

For calling runtime functions, we usually just have one function that
handles all types.  We can bypass most of the resolution work by just
skipping to that function.

cpython can be observed setting softspace on an object even if it doesn't start with it.
the getattrInternal in softspace() throws an exception the first time through since the
attribute isn't present.  if we don't turn around and set it on the object, we throw
every time we print, which causes a pretty large perf regression (from ~6 seconds to ~17 seconds.)

Previously we would keep its elements alive but not the actual array itself?
I think this is what was crashing fasta.py, which is now working with
this change.

I couldn't reproduce the presumed bug in a smaller testcase though.

Mangle functiondef and classdef names in the type analysis

Marius beat me to the punch with the fix this time :)

Fix a threading.local() and a unicode type analysis bug and add support for round(f, 0)

The GC did not visit the thread state dict, which made it forget it's entries after a gc collection

We support the \u, \U and \N escape sequences and
the unicode_literals option.
In addition updates pypa to latest version with unicode support.

Including the ability to set __class__

Previously there was no way to reliably run the default setattr
behavior, which can be requested by calling object.__setattr__
or PyObject_GenericSetattr.  When those were called, we would
check to see if there is a custom __setattr__ defined and then
try to call that.  But users can and do define custom __setattr__
functions that defer to object.__setattr__, so we need a way to
run the default behavior without deferring to a custom setattr.

Make dict.fromkeys a class method

I think these are getting accessed but not used right now

2-arg iter() variant
bytearray(xrange(256))
better support for multiple inheritance from both old- and new-style classes
set.pop()
str.rindex
set.discard

__setattr_ and thread._local

(scratch space is pre-allocated stack space since the IC can't
allocate new space itself, in order to have unwinding work)

Allocate a fixed amount (currently: 40 bytes) of extra stack space
in our runtime ics.  This involves changing the function prologue+
epilogue to do more rsp adjustment, and modifying the .eh_frame sections
we generate.

One tricky thing is that we currently use frame pointer elimination
in our runtime ics, but the rest of the scratch space logic had assumed
the scratch would be rbp-relative, which I had to convert to rsp-relative.

This should help with sys_argv breaking.
Hopefully it doesn't introduce too many re-calculations of the
CPython expected output.