tiering refactoring

This was vistigial from the old llvm interpreter, where we it made a bit more
sense.  Now it's just weird, and caused the tiering logic to be spread into
weird places.  It was also the source of some bugs, since when we would deopt
there's not really any relevant CompiledFunction that represents the deopt
frame (this is why type speculation had to be temporarily disabled).

So instead, make it so that the interpreter (and by extension, the baseline
jit) work on the CLFunction directly, since the CompiledFunction didn't hold
any relevant information anyway.  This require a whole bunch of refactoring and
API changes.

This commit doesn't actually change any of the tiering decisions (I think), but
should just make them clearer; the actual behavioral changes will be done in
upcoming commits.

Module-level code used to return void, but this causes some
special-casing, so switch to having them return None.
Also, CPython has their module code objects return None, so
it's a small compatibility gain as well.

Specify older 'mock' version to unbreak sqlalchemy

Small fixes for the baseline JIT

Fix irgen bug for instancemethods

We would try to statically-resolve their getattrs, but there's some
special casing in the getattr logic for them.  Which should be handled
by moving the special-case to a proper tp_getattr, but for now just
add the special-casing to "hasGenericGetattr" as well.

Refactor offset macros to use the C++ built-in instead.

More small improvements

This probably doesn't matter that much since I don't
think the function names get used during execution,
but they get seen by tools/annotate.py

ie instead of generating the call to compare(AST_TYPE::Is), just
directly do the pointer comparison in LLVM IR.

For c extension classes that define it.  This makes
unicode-subscripting much faster.

An assortment of misc small perf changes

Put the common-case (where we don't do any work) in an
inline-able function, and keep the slow stuff hidden.

At this point, this is only used for some rarely-used
targets like "disassemble this bitcode".

Plus a benchmark of the getattr() function.
I have some ideas on how to make this faster, but I don't
think it's that important at the moment.

Be more consistent about "ip" while unwinding

rewriter optimization; switch things away from compareInternal

rewriter: use lea to allocate stack space

compareInternal should probably just call PyObject_RichCompareBool
eventually, but the switch also has the benefit of avoiding an
extra boxing step.

Unicode-creation optimizations

I think the ip we receive is the return address to that stack frame
(at least in the non-signal case).  This makes things a bit weird
since the "is this ip in this range" tests have a different half-openness
than they normally do.  At some point an "ip = ip - 1" snuck in, which
I think was to address this issue, but I think it's better to not
change the ip -- ie the resulting address is not independently useful (it's
in the middle of an instruction); we could pass it around as "ip_minus_one",
but instead just try converting the tests to be better.

Since we don't memset the unicode allocations any more, and
we now use a precise gc handler, we have to be careful that
unicode objects are valid enough whenever a collection could
happen.

The issue was that "unicode->str = gc_alloc(...)" could cause
a collection, in which case the collector would go and see a
bogus value in the ->str field.  Now, do the str allocation
first (since it is UNTRACKED) and then do the precise allocation
second.

Inlining the allocation + object initialization saves
a decent amount of overhead, since most of the properties
will be fixed.  For example, the size of the main allocation is
fixed, so we can directly allocate it from the correct SmallArena
bucket.  We can also skip all the indirect function calls.