Promote schema version to a top-level entity.

All aspects of an application except its name and schema file format
have been extracted to a new `VersionSchema` type.  Applications are
now lists of versions.

In addition to the name and format, they provide a current version
number which must match a declared version.

By tracking past (or future) versions this way, it's possible to infer
the types of rows defined by versions other than the current one.
Tweak some spec names and docs.
Relations form a map instead of a list underneath tables.

The names they're given are arbitrary, but will be used to identify them later in the API.
Version numbers must be unique across the application.
Relation names within a version (not just a table) must be unique.

An argument can be made that disambiguating them within a table is
enough, but this allows us to assume a current version number and
address relations directly without mentioning tables.
Type.names returns the NamedType labels within a given type name.
Qualifiers form a map under family, instead of a list.

This allows a schema author to give them arbitrary but fixed names.
To be clear, the thing receiving a name is the template that
qualifiers (which are runtime bits of storage) are created from.  This
lets us discuss similarly-typed qualifiers in named sets.
Type.is_constant? determines if a type name represents a constant.
Refactor Type.is_packed? and .is_named? to use java type checks.

It's drier.
version_column refers to qualifiers by name.

Since qualifiers now have names, we can just use those.

The qualifier_types of qualifiers named by version_column attributes
are also now required to be constants (a constraint I intended all
along & apparently overlooked it.)
NamedType type labels must be unique from a qualifier to the root.

By that I mean a given qualifier's value type, qualifier type and
owning relation's row key type must not, amongst themselves, have any
duplicate NamedType labels.

In a context of a specific qualifier schema (such as one identified by
a relation name and qualifier name) this implies that there is at most
one way to map a value attached to a particular label onto a cell
described by that qualifier schema.

Note that these type labels are currently not required to be unique
*across* qualifier schemas at any granularity: two qualifiers within
the same family might have value types that share labels.
Review feedback.
Merge pull request #43 from seomoz/phs/make-schemas-cumulative

Phs/make schemas cumulative and uniquify type labels