tdb2: check PID if we are holding a lock.

tdb2: check PID if we are holding a lock.

tdb1 has tdb_reopen/tdb_reopen_all, which you are supposed to call
after a fork().  But we can detect PID changes whenever we grab a lock,
which is to say, before we do anything.

We currently assume that pread and pwrite work, so the only problem
with fork() is if we are holding locks and expect them to still be
there in the child.  This is unusual, but most likely caused by a
fork() inside a transaction.  In such cases, allow the child to unlock
without complaint; they can then use the TDB as expected.

Performance before and after shows no measurable speed difference:

Total of 5 runs of tools/speed 100000:
Before:
	Adding: 18899ns
	Finding: 7040ns
	Missing: 5802ns
	Traversing: 6466ns
	Deleting: 12607ns
	Re-adding: 14185ns
	Appending: 20770ns
	Churning: 93845ns

After:
	Adding: 18073ns
	Finding: 6795ns
	Missing: 5549ns
	Traversing: 6333ns
	Deleting: 12313ns
	Re-adding: 13835ns
	Appending: 20343ns
	Churning: 92208ns