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

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

Fix uses of addGuard(python_object)

Since we are putting more things in the IC gc references,
call GC again after clearing them.

Hopefully this doesn't end up keeping things alive for too much
extra time.

and add the test that exposed it.

addGuard(obj) is dangerous because obj could be deallocated+reallocated
in the same spot, which is what ended up happening here.

VRegInfo: reduce memory usage

bjit: fix memory corruption

we used to destroy the ICInfo before all references to it got deleted.

I run into this when using the glibc alloc instead of jemalloc

SourceInfo: remove the AST stmt copy, remove special handling of lambdas

had to change AST_Expression to store a stmt instead of a expr but this has the advantage that memory managment is easier

use PyObject_Malloc in pyston::DenseMap, smaller ICInvalidator, reduce malloc calls

llvm::SmallPtrSet<ICSlotInfo*, 2> and std::unordered_set<ICSlotInfo*> have the same size
but the SmallPtrSet has the advantage that it can already store 2 elements in there and does not allocate 10 elements in the constructor

it is slighlty faster for small allocations and has the advantage that it is easier to track how much memory our python objects are using

runtime ICs: use mmap instead of malloc for executable code

don't handle functions containing lambdas with yields as generators

make inner links to dir format

I'm suprised we did not run into this earlier...

use more often std::unique_ptr

This stuff got mostly already manually freed but I think this change makes it a little easier to see who owns what.

we should not execute memory which got allocated using malloc
(crashes a lot of memory inspection tools and also the windows subsystem for linux)
I replaced it with a trivial mmap allocator which never unmaps the memory
(but reuses the memory if a runtime ICs gets deleted)
I think this is fine for now:
- there are <100 runtime ICs used per test
- because all runtime ICs have the same size there is no problem with fragmentation

ICSlotInfo: remove old invalidator entries

delete the llvm module after code generation

this saves a lot of memory

Switch to CPython list sort(Not its list implementation)