Support added to initialize a tuple using the tuple type class.  Allows
creation specifying positional or using the keyword argument 'sequence'.

Accepts iterables- tested with lists, tuples, sets, dicts and strings

Need to special-case some places in the keyword handling
since they previously assumed that they would first have
to check if the keyword name matched a positional argument,
before putting into the output **kw.

errnomodule.c is extremely simple and doesn't do anything complicated,
so this is more of a proof-of-concept for now.
The tricky stuff will most likely be around newly-defined types.

The previous code assumed that there was only one stack per
thread, which could be examined by looking at the current registers.
Generators complicate that, since we switch to a separate stack.
We still need to scan the original, main stack, which means that
we need to add some bookkeeping code that remembers what the main
stack was, even as we swap to and from generators.

Nothing major was wrong, but was trying to double-pass the
generator/closure arguments.

Previously the gc header had to be set and managed by the user of the GC,
which didn't make much sense.

Also took this opportunity to clean up a bunch of old cruft.

Also got rid of ObjectFlavors and AllocationKinds, in preference for
a GCKind which I think makes more sense.  Right now there are only three
different GCKinds, but I'm not sure if the previous AllocationKinds
should each get their own GCKind.

Conflicts:
	src/runtime/str.cpp
	test/tests/str_manipulation.py

Added capitalize and title functions for strings

Implement tuple.__add__, dict.__contains__ and builtin id() function

removed dict_contains.py
fixed merge miss in dict.cpp

The goal is to be able to use these as-is

Rewriter2

Conflicts:
	src/runtime/dict.cpp

ie actually add one.  Before dict.__new__ would simply call
object.__new__ and return something that was very much not a dict :/

Currently returns the address if the Box*

TODO: When using {} to construct the dict, contains works. However
if the dict type is used, the runtime crashes in various ways (see
tests/dict_contains.py)

We were caching certain liveness results (only crawled each BB once
looking for name use/defs), but we were still traversing the entire
CFG for every liveness query.
Now, each query does a single full CFG scan, and computes the results
for all BBs and stores them.

Reduces the time to 'import re' from about 13s to under 2s.

This commit is a straightforward implementation that doesn't include
any speculation-like optimizations.  For operations that can overflow,
just relax the type-return-specification to UNKNOWN, and do the overflow
checks in the runtime.  This means that we no longer emit fast native
integer instructions even if we know operands are ints.

Will have to add optimizations:
- range analysis so that we can know there won't be overflow
- deopt-on-overflow so that we can work with unboxed ints even if there's potential overflow