for getattrFunc use getattrInternal instead of getattr

Float pow

getattr throws an exception if the attribute is not present.  getattrFunc already throws the same exception (if there isn't a default value passed in).

Add a section-ordering script

I think this lets us specify that certain functions should be
put together at the end of the text segment.

This is inspired by a similar feature of HHVM's build, though the goal
for us for now is just to improve performance consistency rather
than overall performance.  Hopefully soon/eventually we can do
profile-guided sorting like they do.

Fix some issues with the way we build libunwind

First, that we would only apply our patchset once.  If we ever revert the
patches (I'm not sure under what conditions that happens), we previously would
never apply them again.  Attempted to fix this by adding a special patch that
adds a new file that CMake looks for; if the file doesn't exist, cmake runs the
patches again.

Second, that we didn't rebuild libunwind if we apply new patches.
I'm not sure if there's a good general solution to this, but I was able
to figure out how to force libunwind to rebuild if we need to rerun the
patch command.  It took some hacking since CMake doesn't track dependencies
on external projects, so we have to add some custom dependencies.

remove redundant -Wno-sign-cmopare

Switch hash to using tp_hash

We weren't even doing any rewriting for hash, so there's not much
downside.  This also cuts down on boxing quite a bit since
we can usually avoid boxing the hash value.

Perf investigations

Coming from looking into regex performance; re_compile is reduced
from django-template startup, and dict_hashing_ubench is reduced
from that.

Also, quiet some debug output

use llvm::StringRef instead of std::string typeNew

turns out we allocate/free the same std::strings for every slot name, for every typeNew.
instead do it once, when we create the slotdefs array.  Also, use llvm::StringRefs instead of
std::strings since we already have them in setattrGeneric (the other caller of update_slot.)

Add UTF8-BOM support, int.bit_length, function.func_doc, fix '(-1)**0'

Python-level sampling profiler

Uses setitimer() to set a recurring signal, and prints
a Python stacktrace at the next safepoint aka allowGLReadPreemption.
This is not great since allowGLReadPreemption can happen a decent
amount later than the signal.  (I'll play around with trying to get
the signal to be acted on sooner, but it might be better to wait
for full signal-handling support.)

Still, it seems to provide some decent high-level info.  For example,
half of the startup time of the django-template benchmark seems to be
due to regular expressions.

Handle list self assignment during slicing

Add some parsing tests

- byte order marker
- newline between decorator and its function
- strings with size >64k [including a fix]

also, a decimal.Decimal test

Add PyErr_GetExcInfo, make __builtins__ more similar to cpython and id() output more useful

Convert runtime functions to take llvm::StringRef

This only happens to me on the gcc build, and it apparently doesn't
happen on travis-ci.  Not exactly sure why that would cause the code
to get linked or not, but anyway it's stuff we're not using right now
so just ifdef it out.

Should hopefully cut down on allocations to pass around
'const std::string&' objects (since we don't always store things
as std::strings anymore), or to calls to strlen if we pass around
const char*s.

Haven't looked yet at the calls that we embed in the llvm IR.

Here are the perf results:
  pyston django_migrate.py                  :    2.3s baseline: 2.3 (-1.7%)
  pyston django-template.py                 :   15.1s baseline: 15.4 (-1.6%)
  pyston interp2.py                         :    5.3s baseline: 6.3 (-15.1%)
  pyston raytrace.py                        :    6.1s baseline: 6.2 (-0.7%)
  pyston nbody.py                           :    8.4s baseline: 8.1 (+4.1%)
  pyston fannkuch.py                        :    7.5s baseline: 7.5 (+0.2%)
  pyston chaos.py                           :   20.2s baseline: 20.0 (+0.7%)
  pyston fasta.py                           :    5.4s baseline: 5.4 (+0.3%)
  pyston pidigits.py                        :    5.7s baseline: 5.7 (+0.0%)
  pyston richards.py                        :    2.5s baseline: 2.7 (-6.2%)
  pyston deltablue.py                       :    1.8s baseline: 1.8 (-0.0%)
  pyston (geomean-3424)                     :    5.7s baseline: 5.8 (-2.0%)

I looked into the regression in nbody.py, and it is in an unrelated piece of
code (list unpacking) that has the same assembly and gets called the same number
of times.  Maybe there's some weird cache collision.  It's an extremely small
benchmark (a single 13-line loop) so I'm happy to write it off as microbenchmark
sensitivity.  We can also optimize this if we want to; we could speculate on the
type that we are unpacking and inline the parts of the unpacking code we need.

switch to CPython's thread._local implementation