Lower initial dict/set size from 64->8

Support non-module-globals in the llvm tier

By switching to our DenseMap/Set fork with that allows parameterizing
on this.

This is the same number that CPython uses.  We were previously
using llvm's default of 64, which is pretty high -- probably fine
for their use cases, but in Python programs with lots of sets/dicts
we spend a lot of time doing malloc() for all those 1kB+ allocations.
This also increases the time it takes to iterate over the dict/set,
since there are more empty buckets that have to be read + skipped.

The default is 64, which is quite a lot for our uses.

- add note + license
- put in our namespace
- change header guards
- make it match our lint style
- don't apply our formatting

With no modificaions in this commit, so that we can track changes.
Unmodified from llvm rev r230300.

It does use the old parser, but it also forces the use
of the llvm tier for everything which usually ends up being
the more important part of the configuration.

(motivated by namedtuple)

This involves two main changes:
- changing the calling convention to pass `globals` as an argument if needed
  (this only applies going into compiled code, it's already passed into the interpreter)
- changing the llvm irgenerator to use the new globals object

Notion of redundant visits to slowly move towards scanning everything

Complex improment

when calling a BoxedWrapperDescriptor don't create a BoxedWrapperObject

For marking collectors, the redudant visits no-op to avoid the
performance hit.

- use callattr directly instead of getattr+runtimeCall
- compvar: teach it that None is never nonzero

BoxedWrapper optimizations

In order to allow rewrites.
I'm wondering if we can't enable this for more classes...

Before we created a tuple just to pass 1 or 2 args and then immediately extracted them
and destroyed the tuple again.

Move closer towards exposing the public gc interface only in one file.

Rewriter "aggressiveness" and backoff

We often have cases where the "attr" part of a callattr can be rewritten but
the "call" part cannot.  This change lets us be able to rewrite the getattr
and then write out the call as a call just to runtimeCallInternal.

Add a concept of rewriter "aggressiveness" that decreases over time.
It starts off high and we will try to rewrite everything fully, but
as we succeed too often (megamorphic) or fail to rewrite, we will
decrease the aggressiveness and produce more generic rewrites.  This
means they are more likely to succeed both at the rewriting stage
and at the execution stage.

Previously, we would inspect the combination of (return_value, exception_state)
to try to determine what the behavior of future rewrites will be.  For example,
if no attribute was returned and no exception was thrown, then we would assume
that all future times through the rewrite the behavior would be the same.  This
has caused a few bugs, and I'm about to add other cases where it won't be possible
to examine the current function's return value to determine what the future
rewrites will do.

So instead, have getattr-like functions return a "rewriter return convention" flag
that says how future rewrites will behave.

3-arg execfile

Rewrite some more typeCall cases

Some random runtime function optimizations

misc small perf improvments