As the locking issues with enlarging a hash were so nasty, we switch to a
tree structure for the entries.  It's a hash which expands to point to
sub-hashes when it fills.

This means we no longer have a 'volatile' header: the top hash cannot move.
In fact, we no longer store a copy of the header in the tdb_context; we only
need hash_seed.

New helper functions for accessing writable areas and committing the results
(if they had to be copied).  New debug test to make sure we don't hold access
while we're doing something which could cause us to unmap/remap.

Find becomes more complicated: we need to track where we found (or didn't
find) an entry so we can easily add/delete it.

Traverse becomes more complicated: we need to track where we were in the
hash tree.

This eliminates all the "drop lock and retry" logic: we expand inside alloc().

We put the free lists at the beginning of a zone; this means no record
can be larger than a zone, but means they cannot move.  Once we change
hashes to be expanding, they won't move either and the result should be
simpler.

The unreserved headers were a real bug; the others could cause a false error too.

We were not actually recording valgrind failures in ccanlint!

These tests revealed more bugs with delete (rewritten) and hash enlargement.

Use hash_add() when resizing hash, too.

This explains why most of tdb_gradual_lock was not tested: thanks gcov!

eg. -v dumps percentage of coverage, -vv dumps per-line data, -vvv dumps every command executed.

This means parallel "make check" works again.

This prevents us from writing out gcov files.

- Neaten I/O function
- Don't use fill in zero_out: it's only for low-level ops.
- Don't mangle arg in tdb_write_convert: it broke write_header.
- More use of tdb_access_read, make it optionally converting.
- Rename unlock_range to unlock_lists.
- Lots of fixes to enlarge_hash now it's being tested.
- More expansion cases tested.