PhysicsFS thread safety.

[Ryan C. Gordon]

I caved.

I've added a mutex abstraction layer for PhysicsFS's internal use, and
have made a first stab at thread safety in the library.

The only thing that probably isn't thread safe is manipulating the same
file (reading and closing at the same time, writing twice, etc) from two
threads at the same time. This is generally a problem with the
application, so I'd rather not bog down the library with mutex contention
on every bit of file i/o. Note that this is a matter of things like
PHYSFS_read() not being mutex'd...reading two separate files from the same
ZIP archive simultaneously _is_ thread safe.

Code that needs to touch the linked lists for the search path, write dir,
or the open file lists are all guarded by a single mutex. In theory, a lot
of the API is blocked by one lock, but in practice, there are all things
you do during setup or rarely during a run (enumerating a directory's
contents, setting the search path, seeing if a file exists, etc...). The
hardcore processing chunks (reading/decoding from a zipfile, writing to
disk), are not protected by this mutex.

The linked list of error states that we keep per-thread is guarded by a
separate mutex, since lots of things set errors even if they are
non-fatal.

This should work on Linux/Unix now, win32.c needs to be updated with four
mutex functions (create, destroy, lock, unlock). Zeph should be checking
in his win32 file i/o abstraction code soon (today?), and hopefully the
mutex code will follow shortly thereafter, so you Windows people can get
up and running with the latest-and-greatest again.

In the meantime, if anyone's bored, I need people to check if unix.c still
compiles on non-Linux Unix platforms, and I need someone to stress test
the code.

Actually, a "stresstest" command in test_physfs would be cool.

--ryan.