Add cmath module and fix some bugs discovered in test_cmath.

Don't generate patchpoints for calls to fixed functions which don't need patching

Inlining it causes a perf regression

because when calling a function with return type BOOL we currently expect it to return a i64.
This got triggered by the inliner

Previously we generated patchpoints for every call because the callee could do a frame introspection
and we could not retrieve the frame info without the additional patchpoint informations.

This change moves all required information inside the FrameInfo.
Because the FrameInfo does not have a fixed offset (different num of stack args and OSR functions reuse the frame info from the interpreter),
we generate at function entry a stack variable which points to the frame_info and than we emit a stackmap intrinsic
in order to know which basepointer relative address it has.
The current statement inside the FrameInfo gets only updated on direct calls - patchpoints still attach it directly instead of updating the memory.
Because always updating the variable is a small slowdown.

This allows us todo inlining of trivial call sites at the llvm IR level.

Cheaper frame introspection

Just move some fundamental functions, the others are not,because Pyston'scomplex object format is different from CPython's,
so leave some function in complex.cpp and use current implementaion is a acceptable.

More debugging tips.

clang-3.7 support

Some small documentation

Not sure how we ended up with the '-1' everywhere.

And also detect attempts to compile on a 32-bit system and
quickly give a nice error message -- fixes #1018.

This splits up the handling of deopts and normal frame introspection (e.g. for a traceback).
We have to add to nearly all call sites frame introspection which makes it very important that it does not introduce much overhead over a normal call instruction.
By always storing the user visible variables into a vregs array (layout the same as in the interpreter/bjit) we can make introspection cheaper.
Frame introspection only needs to access user facing variables therefore we don't have to generate extra bytes for spilling variables which get clobbered in the callee because all values we need to access are inside the vregs array.
This let's use remove the 95byte overhead and reduces the stackmap size.
It adds a slight cost of maintaining the vregs array but we were already doing some of this work before with our manual spilling with the additional benefit of faster frame introspection.

The deopts case stays pretty much the same with the exception that we don't add the user visible vars to the stackmap because they are already in the vreg.
We could reduce the overhead by implementing a special "deopt()" function in asm which stores and restores all variables thereby we would not have to manualy spill the registers when filling the deopt IC.
Alternatively we could handle it inside llvm by either switching to a stackmap intrinsic which already supports this case or adding it it does not exist...
But I think it's not worth it because deopts should be uncommen...

Based on recent issues I've encountered working on running the
NumPy test suite.

move ICSetupInfo before PatchpointInfo in anticipation for accessing ICSetupInfo inside the PatchpointInfo

Changing the INSTALLING instructions. 

Test file for paste (and py.test) modules

Fix build error caused by missing 'override's.

Add a clang libTooling example

Update "roadmap" in readme

Surprisingly hard to get the build to work.  I feel like no one must use
libTooling for out-of-tree projects.  Also, the binary can only be run from
the directory in which it would have been placed for an in-tree project.

It was going to be a refcount discipline checker, but I'm not sure that's
a good use of time right now.  I want to check it in though so that we have it.

- add small 0.5 blurb
- add 0.4 blog post link
- reverse order (latest release first)

microbenchmarks for the presentation