descriptor/format fix

bjit: don't generate a 'getGlobal' call for 'None'

Some improvements for int to let test_int could pass

add instanceTrunc to old style class, but not expose the API, just let instanceInt call it when the inst don't have __int__ attr

Copy tp_as_number *after* commonClassSetup

Was a descriptor issue where we were interpreting 'None' as 'no argument'.
I think this only gets triggered when pip has to do a http retry, which is
why it only sporadically made the tests fail.

To specify the lack of the second argument.  This improves compatibility
when applying descriptors to the None object itself.

This was showing up since we were trying to call None.__format__

Add float_info to sys module, and rewrite version_info use SequenceStructure

This is important because commonClassSetup will modify tp_as_number
if it exists.  This causes an issue when an extension class uses
multiple inheritance; it will inherit the tp_as_number from its
main base, but then copy in any fields from its secondary bases. But
tp_as_number points to the same struct as its parent, so it would
update the parent's slots accidentally.

So, move the tp_as_number copying to where CPython does it, or at least,
after the calls to inherit_slots.

Add more __repr__ attributes to our builtins

Switch our Python set implementation to use a llvm::DenseSet

Microoptimize the rewriter class

Improve the float implementation, enable test_float

make `int("some_random_string")` faster

Probably more compatible, but also much faster.

Also, set str_cls->tp_repr.

We currently over-build it quite a bit; I'll try to look into that
issue, but for now we can lessen the effects by at least building
it in parallel.

Allow string + bytearray => bytearray. Fixes #780

improve getattr() speed

We're keeping them around anyway

Our exception throwing is still slower than CPython's, and it looks
like it's partially due to the CAPI calls we do as part of the throwing
process.  For example, we have to actually create an exception object,
which involves calling the exception type constructor, etc.  We could
try to jit this stuff, but for now add another fast-path to typeCall
that should catch some of this.

Also, add a fast-path that inlines most of the exception-creation behavior.
Looks like this isn't too much faster than the above-mentioned fast-path.