Sort build.ninja contents in relatively stable way.

This makes it significantly easier to diff output across versions,
particularly versions that change the env representation, and thus the
hash.

The current key is (type, path, env?) where type indicates the top-level
output directory (gen, env, latest) and env? is a digest for
context-sensitive products.

Because this is merely a permutation of the contents of build.ninja, it
should have no user-visible impact (no rebuild).
Avoid deep-copying during env derivation.

I've switched the representation of vector values in the env from lists
(mutable) to tuples (immutable).  There's no syntax change; you could
write tuples in the BUILD files, but you can still write lists and
they'll get converted.  (Since the single-element tuple syntax is
idiosyncratic this seems like a good thing.)

I've also added some more explicit type filtering to try to ensure that
Env only contains value types.  (Or types that lie about being values.
We are in Python, after all.)

There are two main implications of this change:

 1. Env only needs to do a *shallow* defensive copy to ensure its
    immutability.  This is a lot cheaper.  Deepcopy was the init
    algorithm's hotspot, and the algorithm is now ~6x faster.

 2. Because the Env hash algorithm is sensitive to the representation
    of values (it uses cPickle), all hashes have changed.  This will
    force a rebuild when you pull in this version.  The reliance on
    cPickle is admittedly a hack.

Beyond the hashes, I've scanned over the outputs and see no changes.