Similar to the location of the dict attribute in CPython,
the 'hc attrs list' in Pyston will end up being located at
different offsets, depending on the class that's being subclassed
from.

This commit removes the HCBox class, which assumes that it always lives
at the same offset and so can be statically described with a C++ class,
and instead uses a runtime lookup.

This should hopefully make things a fair bit closer to supporting inheritance.

Add (modified) spectral_norm millibenchmark from the language shootout.

Implement tuple hashing

Implement zip2

Implementation of dict comprehension

Signed-off-by: Vinzenz Feenstra <evilissimo@gmail.com>

Signed-off-by: Vinzenz Feenstra <evilissimo@gmail.com>

Implement list.index()

LivenessAnalysis: Cache BB liveness info to improve performance

Move some things to calling the *Internal methods,
which don't do patchpoint-checking, which wouldn't apply.

Reduce some unnecessary string-creation.

Also fix some of the things that it reported.

Have to patch the tool to make it work, since it wants
to use the CLANG_CXX environment variable to pass information around,
but the Pyston Makefile uses that variable as well.

Signed-off-by: Vinzenz Feenstra <evilissimo@gmail.com>

Signed-off-by: Vinzenz Feenstra <evilissimo@gmail.com>

Brings down runtime of gcj_2014_1c_b.py from 2secs to 0.7

implement del x[idx], x[start, end, step]

implement list.reverse()

Before was using some bad iteration strategies for
fixed-point computation: LIFO for definedness analysis
(very bad), and FIFO for type analysis (bad).

Switch both of them to use a priority queue that picks the
block with the lowest index; this is an order of magnitude
better on the new gcj test but still is fairly slow.

Added some string functions and fixed a couple bugs.

Also, give up on maintaining 100% error message compatibility
with CPython.  There are some places where it's kind of silly
to do this since the messages seem based on internal implementation
details; namely, whether to output at the global scope:
NameError: global name 'x' is not defined
vs
NameError: name 'x' is not defined
This depends on whether any function has been defined that has
a "global x" declaration.

Instead, make the tester a little bit smarter to know that certain
classes of error messages should be treated as equivalent.

Not quite as small as microbenchmarks, which primarily
test just a single feature, but not full benchmarks either.

Will add them back later