We could also add more general rewriting, but
- these new special cases catch something like
  95% of the cases that we weren't rewriting
- these special cases are faster than doing the generic
  nonzerno mechanism (looking up the attribute, etc)

It'd be nice if we could get to the point that the generic
rewrites we'd create would be as good as the hand-crafted ones,
but that would require knowing that we don't need to guard on
constant classes, and then inlining within rewrites.

Some more perf hunting

ie one of the common entrypoints to capi code.

ie when it's on a builtin method.  We assumed at some point
that we wouldn't need to look at the function object, but now
that we can rewrite method_cls calls, that's not true.

Playing with stattimers

ie roll up all the time into the most "avoidable" reason that we were doing it.
For example, if we are doing something like calling slot_tp_getttro on a builtin
type (very avoidable), roll up all the subsequent time (runtimeCall, etc) into
the slot_tp_getattro timer.  But if we call runtimeCall where we couldn't avoid it
(ex from the interpreter), log that separately.

Not sure how helpful it will be but for this specific investigation it seems to
somewhat work.  The idea of the "avoidability" is definitely pretty specific to
the type of work that you are thinking of doing; the numbers I put in are for
investigating slowpaths.

Also, remove all the timers that we have on specific runtime functions (ex: listMul).
I think we'll need another strategy for those.

Switch super to tp_getattro

Some small micro-optimizations

Mostly related to making sure that some hot paths get
inlined better, particularly for allocation/sweeping.

These changes make a simple for-loop benchmark (which
is just dependent on allocation speed) about 25% faster.

Incremental traceback

constant loading optimizations in rewriter

cmake testing

- Reuse a register if it already contains the specified value
- Generate LEA when beneficial
--> Generated code is smaller and has same or better performance

make BoxedTraceback hold a single line, instead of a vector.  rename BoxedTraceback::Here to BoxedTraceback::here

move the exception stat logging to PythonUnwindSession::logException, which is called from cxa_throw.  remove raiseRaw and make raiseExc use throw

end the unwind session by setting the is_active flag to false.  if the unwind session isn't active we don't mark through the ExcInfo, so exceptions/tracebacks should get gc'ed properly.

1. remove the BoxedTraceback** argument from maybeTracebackHere.  the unwinding.cpp
   code can get it just as easily.
2. combine UNWIND_STATE_OSR and UNWIND_STATE_RERAISE into UNWIND_STATE_SKIPNEXT,
   since they share the same behavior.
3. put the SKIPNEXT behavior in the callers of unwindProcessFrame.  Now unwindProcessFrame
   does nothing but create a PythonFrameIteratorImpl (if it can), and if it can
   calls its callback with it.
4. initialize the unwind state to NORMAL in raiseExc.

move unwind_state to ThreadStateInternal.  move the class decl to threading.h and ensure the small/hot accessors are inlined

stop using 'WHY' just to be similar to cpython.  'STATE' is better.  also, reduce duplicate code in unwindProcessFrame

store the exception ferry (as an ExcInfo, not ExcData) within our internal
thread state, and explicit visit type/value/traceback at gc time.

This allows the gc to run during an unwind (a necessity since
we're allocating new BoxedTraceback instances)

Add a tb_next to the BoxedTraceback object, which during normal unwinding is how we add lines to a traceback.
For getTraceback() we take advantage fo the fact that each BoxedTraceback can have multiple lines in it, and
only create one.  Also add BoxedTraceback::Here which is kinda like PyTraceback_Here, except that since we
don't have access to the ExcInfo inside it, we have to pass a pointer to the BoxedTraceback*.

three wrinkles in traceback generation while unwinding are:

   1) if the previous frame was an osr frame (so we should skip the current frame)
   2) if the traceback object was passed to raise3, or raise0 was used (treated as a re-raise by cpython)
   3) the interpreter map

1 and 2 are fixed by keeping a per-thread interpreter state variable, "unwind_why" ("why" is probably
a bad name to use in this context, but cpython's logic uses that word as well), to record if we're in
either of those cases.  Both cases have the same effect (skip the next traceback line, and reset state
to NORMAL.)

The interpreter map problem comes about because of the way c++ unwinding works.  since ASTInterpreter::execute
uses RAII for RegisterHelper, unwinding through the frame causes us to jump to a cleanup block and then resume
unwinding (with the IP still in ASTInterpreter::execute).  Since the IP is there, we assume the frame is valid
and we can look up $rbp in the interpreter map.  Given that we just cleaned up the RegisterHelper (and removed
the $rbp mapping), we crash.

The fix here is to keep the same RegisterHelper in ASTInterpreter::execute, but the ip checked for by the
unwinder (and the $rbp in the mapping) correspond to ASTInterpreter::executeInner.

Lastly, AST_Interpreter::invoke catches exceptions, so we won't make it to the top-most ASTInterpreter::execute,
and so won't add the final line.  We make use of BoxedTraceback::Here here as well to add the final line.

Rewrite "a in b" expressions