Merged in changes from Evan's branch that allows the system to
continue commiting transactions when there is a failure of only one
data manager in the last phase of two-phase commit.

inconsistent data. Added a detailed comment with explanation.

Added explanation of the semantics for calling the function passed to
the storage tpc_finish method.

important for ZEO, which may need to get tickled to get updates in
non-aynchronous mode.

This was to get a newer asynccore (or ZServers) if possible.

to database connection leaks when the mount point object was garbage
collected.

if an attempt was made to write while disconnected from the storage
server.

defaults to the present and a 'days' keyword argument can be used to
specify a number of days pervious to the time to pack to.

A wait keyword argment can be provided for pack that causes the client
to wait for a pack response from the server. NOTE: no other requests
will be sent to the server while waiting for the pack response. This
feature should only be used from utility packing scripts.

Got rid of the no-longer-used (synchronous) store method.

Added a wait argument to pack.  If the wait argument is provided,
then the pack method doesn't return a value till packing is done.

Simplified the way errors are handled in normal calls and
packs by putting the error marshalling logic into a separate
method.

No longer log UndoError, VersionCommitError, and TransactionError
exceptions on the server, since these are user-level errors.

Do log pack errors.

defaults to the present and a 'days' keyword argument can be used to
specify a number of days pervious to the time to pack to.

Rearranged handlers to make them a little less signal dependent.

"address already in use" errors.

editorial changes.

files if no directory was specified in the var directory and if
INSTANCE_HOME isn't set.

between calls from the storage and from the out-of-band
invalidation message handler.

on start up, with the default being to wait for the server.

The intent was that it should be possible to bring a client up even
if it can't talk to the server, however, this is a little bit risky if
we need to start them both.  Eventually, we need to be the start-up
code be smart enough to wait if we can't serve data requests during
startup, but to proceed if we can.

a memory leak in mounted databases.