Schema Updates, Data Transformation Script

Fixed a typo in a comment in the user.php include.

Made some schema changes driven by a few factors:

1. The source data is not in a good/consistent format.  Data that's
seemingly necessary is missing, and therefore NOT NULL constraints make
the tables impossible to port.  The fields have no reasonable defaults,
and therefore this problem can't be obviated by adding defaults to the
fields.  Going to need some insight from someone with more knowledge of
the requirements to "fix" this.  For now most NOT NULL constraints have
been relaxed.  The only NOT NULL constraint I didn't relax was the one
on the `password` field in the `users` table, just because the login
system doesn't handle that in any reasonable way.  For the time being
I've set the password of anyone who had a password field with NULL or
the empty string as its value to "password".

2. The new schema, cobbled together by a combination of insight by Keith
and I, and a reference schema we were given by Jason, lacked a LOT of
the fields from the old database, fields that were HEAVILY populated.
We're not talking about losing data on a handful of rows, we're talking
almost every row.  So I added those fields back in.  They can always be
removed.

3. Consistency.  Most apparently with the `fax` field (and variants)
added to `organizations` and `users`.

4. Merging data that's duplicated or unnecessarily split.  This is
apparently with the transformation of `province` to `territorial_unit`.
The source data has `otherProvince`, in which U.S. states (among other
things) would go.  This design doesn't make any sense, if you want to
verify that a territorial unit is a Canadian province, that's what the
`country` field is for.  Therefore `province` and `otherProvince` have
been merged into `territorial_unit`, which should make working with the
database easier in the general case.

Made a PHP script to load data from the old schema and place it in the
new one.  This script does a LOT of scrubbing, since the old schema was
badly populated.  NULL was misused throughout, with the empty string,
"n/a", et cetera being variously used in place of it.  The script
handles all of this and populates the `membership_types`,
`organizations`, and `users` tables in the new schema.

Still some questions for Jason or someone else with more knowledge:

-`sameAsOrg` in the old `users` table signifies that the users contact
information is the same as the organizations (?).  This is a highly
denormalized design.  Should this design (or a more normalized one like
it) be maintained, or should user contact information and organizational
contact information be kept separate, or merged entirely?
-`orgContact` is the old `users` table transmits information about
whether this person is some kind of contact for the organization they're
a member of.  But this data is already available in the `organizations`
table (both in the new and old schema).  Are organizational contacts
necessarily users?  Can we use a foreign key to resolve this?
-The old `users` table has a `rolesId` column, which is a foreign key to
a table not in the new schema -- `roles`.  Is this necessary?  The new
schema has a flag for making a user into an administrator, are other
roles still necessary?
-The old `organizations` table has a `gst_number` and `gst_exempt`
field, but these seem to be totally unpopulated.  They're not in the new
schema.  Should they be?
-What does it mean for an organization to be enabled?  How is this
different from paid vs. unpaid?  Is this data duplication or does it
have a distinct meaning?