Optimize creating tuples from lists

small optimization to sre_compile._compile()

Skip initializing exc fields inside JITed code

Switch from expensive old-style-class iteration to our faster iteration.
We could/should probably make old-style iteration much faster than it currently
is for us (10x slower than CPython), but this is a pretty targeted change and
makes compiling regular expressions much faster: it cuts (non-LLVM) _compile()
time by 2x.

cache + reuse 1-length strings

Switch those to just calling 'new BoxedString' instead.

Not sure how much it helps, but it's mostly just a wrapper around
new boxedstring.

Also, I don't think it needs to be in inline/ any more since we
will always box strings during codegen rather than emit calls
to boxString.

CPython does this and seems like a good thing to do.  Otherwise
iterating over a string would cause lots of allocations.

One difference between this implementation and cpython's is that cpython
doesn't eagerly create them, and so it checks to see if they've been
created or not.

Even this is 2x slower

Temporarily disable type speculation

Unfortunately our type speculation strategy has bit-rot
over time, to the point that it's not super helpful.
Deopt (the flip side of the speculation) also has some bugs
in it which I was starting to trigger, so just disable the
whole thing for now.

Turning it off should just be a temporary measure and I'll
look soon into what we need to do to get it back on.

cmake change default build directory, configure script, Fedora support

-pyston build using the copied headers that include the generated pyconfig.h

Conflicts:
	.travis.yml

New benchmarks

Use BoxedString in codegen

Convert to BoxedString much sooner, and have any functions that
might need to box a string take a BoxedString.  This means that
on some paths, we will need to box when previously we didn't, but
for callsites that we control we can just intern the string and
not have to box again.  The much more common case is that we
passed in unboxed string data, but then ran into a branch
that required boxing.

BoxedString shouldn't be that much more costly than std::string,
and this should cut down on string allocations.

For django-template.py, the number of strings allocated drops from
800k to 525k; for virtualenv_test.py, it goes from 1.25M to 1.0M

A couple things made this not 100% mechanical:
- taking advantage of places that we could eliminate unbox/rebox pairs
- different null-termination assumptions between StringRef and the c api.

Based on what Rudi says he was doing (sorry rudi)

Gives you just the top 40 lines.  For use in combination with
watch_%

Add more external projects to our travis-ci test suite

Use the padding bytes at the end of BoxedString

CPython has this optimization as well, and it should
save us an average of 7 bytes per string.

Some `__future__` import stuff

allocate runtime ics using mmap (with PROT_EXEC)

output stderr/stdout diffs for failed tests

free generator even if the don't exit