Bug 4187

As mentioned in bug 4134, we need a mechanism that can let a user log in
and then track who is logged in (via a session cookie) and other bits of
information (in a database, probably).

For the database, we could either ask the fdo people to hook us up with
one in whatever RDBMS they use, or we could go with DBD::Trini or SQLite
or something along those lines, or, in a pinch, flat files.  Then we can
wrap a couple of easy Class::DBI classes around it and use it site-wide.

Basically, what goes on, conceptually, is this:
1. Upon visiting the site initially, the user will be anonymous,
2. If the user logs in (by entering a username and password into
   a form that goes to a login cgi, which checks against the db),
   then two things happen:
   2A:  A record is created in the DB in a sessions table, that
        holds the user id, possibly some other info (such as an
        IP address and expiration datetime), and a pseudorandom
        unique session ID string.
   3A:  The session ID string is sent to the user in a cookie.
3. Any page that wants to know if the user is logged in can check
   the cookie, look up the session ID string in the database, and
   get the user id from the record.  The user id is then also a key 
   into the users table and possibly some other tables.
4. A cron job can periodically delete expired sessions from the
   sessions table; also, when the user logs in, the login script
   could clear out any old sessions from that user before
   adding the new one.
5. When a new user wants to create an account, we ask them for
   (among other things) an email address, and the account is
   created with an inactive status and a datestamp, and an email
   is sent to the provided address containing a magic token,
   which is also stored in the newly created user record.
   The user retrieves the email and feeds the magic token from
   it into the account-activation form, proving the address is 
   valid, and the account is then activated so that the user
   can log in.  A captcha could also be employed if we have
   problems with bogus accounts, but I suspect that will not
   be necessary, at least for now.

The advantage of getting an RDBMS account is that PHP portions of the site
could also access it; whereas, with something like Trini that would be
rather harder to do directly.

Ways this would be used on the site are many and varied, but some examples:
 * The upload clipart form could auto-prefill the author portions
   (both author name and URI); the user would still be able to edit 
   the values before submitting.
 * If we offer a choice of stylesheets, we can store the user's preference
   and always use it when the user logs in.  We could also store preferences
   for other things, such as which sidebar sections to show, and stuff.
 * When the DMS is in place, we can make it so that logged-in users
   can update their own clipart and/or its metadata.
 * Also with the DMS in place, we can make it so that users can leave
   feedback about specific items of clipart; anyone would be able to
   view this feedback, and the author can be notified next time he logs
   in.  Private feedback for just the author is also a possibility,
   if that is a desired feature.
 * With the DMS in place, we can add an interface whereby users can 
   help with categorization, and a given user's contributions in this 
   regard can be tracked, so that if a vandalism problem develops they 
   can be reverted.