Add robust SQL and parameter compiling.

The previous framework for creating a SQL string ready for parameter
binding and execution involved a convoluted system that separated
paramaters from clauses. Now, parameters and clauses are treated as
nodes in a tree and the sub-trees are brought together upon compiling.
All of the parameters for a compiling clauses are extracted and unnamed
parameters are given a named parameter based on the number of current
parameters in the clause.

The 'value' function was eliminated from the Expr prototype to clean up
the syntax. Now, all binary operators accept the right operand as an
argument to the function.
Add argument for binary operator functions of Expr as optional.

To provide greater flexibility in creating a SQL expression, Expr, the
argument to functions representing binary operators is now optional.
Since the right operand is simply pushed onto the tree, it does not
matter if it is passed as an argument or added by function
chaining/cascading. This offers greater flexibility for users in
constructing expressions.
Add common function for all binary operators of a Expr.

Moved the common code between all functions representing binary
operators for a SQL expression to a common 'private' function of the
'Expr' prototype. This reduces repetitive code and follows the Don't
Repeat Yourself (DRY) mentality.
Refactor 'sql' to 'toString' for creating schema.

The 'sql' function was essentially renamed to the 'toString' function
and the old 'toString' function was removed. This was to reduce
redundant and unnecessary code. The original 'toString' function was
added to the prototypes of the 'Table', 'Column', and 'ForeignKey'
objects for debugging purposes, but the SQL is just as informative from
a debugging stand point. Additionally, the 'toString' function follows
the convention implemented with the 'Compiled' object, where the
'toString' function returns a SQL string ready for parameter binding and
execution.
Added factory methods for creating database schema elements.

The more conventional usage of a library is to avoid the use of the
'new' operator and reduce typing. Thus, factory methods, or wrapper
functions, were implemented as part of the library API instead of
exposing the constructors.

It appears from reviewing other JavaScript library and project code and
reading forum posts that constructors within a library should not be
called directly, but exposed through functions attached to a namespace
or module. Factory methods were created to follow this observation.