Templatize runtimeCall for different exception styles

bjit: fix problems when setting bjit thresholds to 1

- we hit an assert when we ran out of scratch space
- 'classobjSetattr' returned void but all runtime funcs must return a Box* object.
- sneak in a change which removes a unused arg from '_setupCall'

Which also involves templatizing most of the things that it
calls as well.

CompiledFunction's now have an additional parameter "exception_style",
and we will try to call a version of the function with the requested
style.  All of our runtime functions are written to the CXX style,
and there's not a whole lot of benefit until we templatize the runtime
functions individually.

implement recursive printing of set and tuples.

start templatizing the runtime to be able to choose exception styles

Fix the errors that report in `test format` and re-enable `test format`.

Apparently they can do compile-time evaluations, which is cool.

For use of PyObject_GetItem

django_template3 ends up calling this a fair amount via unicode_translate
(ie it checks to see if certain entries are in the translation table).

bjit: add support for most common missing nodes and don't JIT compile cold blocks

Numeric binary operator support for old style class

The exceptions thrown by len itself can now be either style,
though any exceptions thrown by any called functions (ex __len__)
will still get thrown as C++ exceptions and converted if needed.

Helps in a common case of "try calling len but don't worry if no
len was defined".

Previously after doing a OSR JIT compilation we continued to JIT every block outside of the loop.
This doesn't show up as a perf change but reduces the number of JITed code / makes it slightly smaller.

w:

list recursive printing

optimize some misc runtime functions

callable(), str(), repr(), PySequence_GetItem(),
and PyObject_HasAttrString()

Mostly by bringing in the CPython versions.

They are tricky since these are types, which means they invoke
the relatively-complicated constructor logic.  ie str() doesn't
just call __str__ on the argument: if the result is a subclass
of str, it calls result.__init__().  Similarly for unicode, except
unicode is even trickier since it takes some more arguments, one
of which is "encoding" which will have non-type-based dynamic
behavior.

I didn't realize that at first and optimized unicode() by exposing an
inner version of it that takes its arguments in registers, which we
can take advantage of using our jit-arg-rearrangement capability.
This means we have to do parts of PyArg_ParseTuple ourselves, so I
added a PyArg_ParseSingle that runs a single object through the
arg-conversion code.  PyArg_ParseSingle could be further optimized if
we want to.  Or rather, if we have functions of the form
PyArg_ParseSingle_s (which corresponds to the "s" format code) we
could skip some more of the overhead.

I had to disable most of that once I realized the encoding issue, but
I left it in since hopefully we will be able to use it again once
we have some "do some guards after mutations if we know how to resume
after a failed guard" rewriter support.

get cpython/test_tuple.py to pass

Get test_iter.py to work