We used to have a installed directory structure that mirrors
our source structure.  This required changing quite a few pieces of CPython
code to look in the new places (virtualenv, distutils, getpath.c, sysconfig).
So, undo all those changes, and change our CMake configuration to install into
the paths that CPython expects.

Note: "the paths that CPython expects" is platform-dependent.  The paths I added
here are based on the "posix" style that it supports.  The CPython code has platform-specific
code to look in different places, and I guess the build system must have platform-specific
knowledge of where to put it as well, but our CMake system will always put it in the linux variant.

Fix pointer reuse problems

while this removes some disabled features I'm not a big fan of having disabled stuff around
because it will break and makes development harder.

this is a duplicate - we will allready emit a call to recordType inside the bjit

solves a pointer reuse problem

Remove libpypa parser

After remove libpypa, the function getMagic only return one string. So
just use a char array constant instead a function.

MCJIT: free loaded objects

This fixes the llvm tier memory consumption until we migrate to the ORC JIT which has better memory management.

Misc memory size reductions

this does not hurt perf but still saves some memory

Threading fixes to get cffi-1.7 working

Instead of having it always point to the thread-local threadstate object,
it's a global that gets updated during context switches, like CPython does it.

There are still a number of differences that should be refactored out, but
I think this should bring us quite a bit closer to CPython's implementation.

It's time :(

This new version is causing some issues for us

switch from the SSE prefetch to __builtin_prefetch

string interning: make it slightly more space efficient

hidden classes: free classes of singleton type

this fixes the huge (~350MB) leak in:
for i in xrange(1000000):
    class C(object):
        pass

We used to store the string content twice.
This implementation makes use of DenseSet::find_as functionality where one can search using a different type.
I was not sure if the special DenseMapInfo I had to create causes any problems so I choose to create a new source file
for it so that it does not get picked up somewhere else.

free bjit code after LLVM codegen

we free now the code blocks after a recompile in the LLVM tier (except for OSR frames) because
it is likely that we will not use the code anymore.
- we have to make sure we are not currently executing any code we will delete that's why I added bjit_num_inside
- there were some cases where we forgot to deregister stuff
- when profiling we don't actually unmap the code in order to not brake profiling

EH: correctly deregister EH frames and cleanup the code 

- previously we never deregistered the EH frame from libunwind (which exposed a bug)
- I removed the calls to register the EH info with gcc since we have our own unwinder which does not need this
- cleaned up the code and fixed some small memory leaks