Locking for concurrent file access (#61)
As we gear up for transactions, the time has come to make sure
reads/writes are correctly synchronized between multiple connections.
The current implementation is very crude, taking an exclusive lock for
any operation on the file. This will be improved in the future when
locking can be guaranteed on certain portions of the file (sometimes
referred to as "record locking") but for now this will do.
One of the biggest challanges with concurrent access (even just with
read only) is that other connections need to know when the schema
changes (such as a table being created or dropped). Once again, this
implements a fairly rudimentary approach that requires connections to
constantly check a schema version flag in the database header before
any operation. If the schema version has been incremented since last
time the whole schema will have to be loaded again.
Some new features with SQL testing to be able to use concurrent
connections and verbose output to test crash situations.
