Add "log hashing" to see new failures

transform BST to gapless bytecode inplace

A common issue is that we see that a test goes from N failures to N+1,
but it's not clear at all which of the failures is new.

This adds a simple hashing mechanism to try to help us in these cases:
we hash each line in the log, and construct a small bloom filter of
which lines were seen.  We can then put this into the test file, and
when the test fails we can run the received output against the expected
bloom filter.

I tried testing it and it seems ok, but we'll have to see how well it
works in practice.

this simplifies the code and removes a lot of ugliness

Get dict ordering closer to CPython's

Typo fixes from PR #1389

- 64 bit hashes in a couple more places
- insert-then-grow, instead of previously doing grow-then-insert
  (changes the order of reinsertion during the grow)

Rather than switching to CPython's dict implementation, which would
be quite a bit of code changes (since we use our internal dict interface
a lot), change our current dict implementation to more-closely match CPython's.

In particular, change the growth strategy and probing strategy to match cpython's.

I'm not sure how I feel about this -- there are still a number of differences.
In theory this is still an improvement over the current status quo (fewer ordering
differences), but I don't know if we need to go all the way and make sure to have
zero ordering differences.

jemalloc: build with profiling support

I think we get one more failure because http://pythonpaste.org/ is down but I'm not totaly sure.
master runs into the same problem but did not 12 days go

cpython encounters the same error
I took the opportunity to switch to py.test from nose
now that we support it and this is how one should test this package.

Minus the ones to code that we inherited from CPython or LLVM,
in order to keep those diffs clean.

- all instructions of the CFG are directly emitted a single memory region
- all instructions are packed and follow each other directly
- the CFGBlock just stores the offset into the bytecode where the first instruction of the block is located
- invokes are only a bit in the opcode field which when set means that the pointers to the normal and exc CFGBlocks* directly follow the normal instruction

Fix attrwrapper comparisons

I really hope this doesn't break anything, but in theory it's a compatibility break
(especially for C extensions).

And add some extra checking to make sure we don't make these kinds of mistakes more

Fix instancemethod comparisons

BST: remove some of the remaining pointers, earlier boxed code destruction

It was previously incorrectly succeeding: we happened to throw a
similar-enough exception that the test thought we were testing the right
thing.  Once we fixed that bug, it turned up that we didn't throw the
exception that the test is expecting.

I don't like removing tests but this isn't any worse than the current
situation of not really testing this functionality.

We had implemented instancemethod.__eq__, but not any of the other comparisons,
and most importantly, not __hash__.

In the future we should just support embedding tuples as constants (of course only when all elements are constant)
and then use this mechanism instead of the 'std::vector<BoxedString*>'

Replace it with a index into a table of definitions and code objects

This also now frees much more code objects early because they get proper refcounted now

we will soon need this

now that the FlattenVisitor is gone nobody uses this anymore

we don't need it anymore now that we eliminated nearly all pointers to nodes.

move constants into CodeConstants, call BoxedCode destructor, cleanup BST nodes

A number of small fixes from the dropbox testsuite

This warning is quite annoying right now