More travis-ci investigations

A fix to the ast interpreter gc visitor

more small perf work

Cache floats based on their bits, not their value

Fix some issues found during a search for another bug

now that the strings get interned anyway.  if we want to continue
down that road of interning BoxedStrings, we could probably do
away with InternedString's entirely.

Allocating things in-line, using malloc-friendly data structures, etc.

Fix a small test output difference on Ubuntu 15.04

- call PyType_Check instead of isSubclass
- unlikely()
- object_cls gets checked all the time but only has attributes that
  start with '_'

The help text has changed...

We were using a C 'double' as the hashmap key, which meant
that 0.0 and -0.0 would end up caching to the same thing.
Instead, extract the bits of the double, and use that as the
cache key instead.

Should fix #724

Add some more debugging for travis-ci builds

We had lost it since I guess `VAR=a cmd1 && cmd2` only applies
the VAR variable to the first command and not the second.

ie for the "repeatedly failing to parse file" error.

rewriter: release allocated scratch space

make attributes interned BoxedStrings

CMake already did this, and I think this is discrepancy is why
if you did `make quick_check`, then `make check_dbg` would fail.

Due to their non-standard bootstrapping, they ended up getting
initialized back to NORMAL hidden classes.  It's silly, but force
them back to SINGLETON.

One of the downsides of the BoxedString-as-attributes change
is that hidden classes become more complicated to gc-scan;
try to claw some of that back.

reenable PyList macros

speed calling of (some) capi code

The real benefit is that we intern the strings that
end up getting used as attribute names, so we can compare
them using pointer comparisons.  It should also reduce
the size overhead of hidden classes, since we no longer
have to copy the string data into the hidden class.

And internStringMortal, which for now just resolves to
internStringImmortal, but lets us mark strings that
could eventually be collected.  (We could use the same
approach that CPython uses and have a string destructor
that removes mortal strings from the intern table.)

well, except that two fields were swapped, and there is an
extra struct wrapper in there.  But with some small changes
we can now let capi code use the list macros for faster list
manipulation.

They're not used any more, and even though they are
empty NopLocks, they change the struct structure.

The main capi calling convention is to box all the positional
arguments into a tuple, and then pass the tuple to PyArg_ParseTuple
along with a format string that describes how to parse out the
arguments.

This ends up being pretty wasteful and misses all of the fast
argument-rearrangement that we are able to JIT out.  These unicode
functions are particularly egregious, since they use a helper
function that ends up having to dynamically generate the format
string to include the function name.

This commit is a very simple change gets some of the common cases:
in addition to the existing METH_O calling convention ('self' plus
one positional arg), add the METH_O2 and METH_O3 calling
conventions.  Plus add METH_D1/D2/D3 as additional flags that can
be or'd into the calling convention flags, which specify that there
should some number of default arguments.

This is pretty limited:
- only handles up to 3 arguments / defaults
- only handles "O" type specifiers (ie no unboxing of ints)
- only allows NULL as the default value
- doesn't give as much diagnostic info on error

The first two could be handled by passing the format string as part
of the function metadata instead of using it in the function body,
though this would mean having to add the ability to understand the
format strings.

The last two issues are tricky from an API perspective since they
would require a larger change to pass through variable-length data
structures.

So anyway, punt on those issues for now, and just use the simple
flag approach.  This cuts the function call overhead by about 4x
for the functions that it's applied to, which are some common ones:
string.count, unicode.count, unicode.startswith.
(endswith, [r]find, and [r]index should all get updated as well)

ie django_template minus the lexing.  We are faster now on the lexing,
but the parsing is where most of the time gets spent.

Also, change this benchmark and django_lexing to have a unicode template.
Usually django does that conversion automatically, but the templates bypass
where that happens, and we end up doing a lot of extra unicode decoding.

Preparation for finalizer code, refactoring some simple_destructor logic.

Convert "a in (b, c)" to "a == b or a == c"

optimize regex handling

some fixes and cleanups

Another 2.7.9 compatibility fix