Tests can be slow to run, and this way we can monitor progress.

We eliminate dependencies as we recurse, but if a single _info file
lists a dependency twice, we add it to the list twice and this skip
over the middle ones.

Rather than a separate cov_compiled member, we can add to the
compiled[] array, and we reduce duplication significantly.

Rather than mug the old ->compiled version when we reduce features,
keep both in the structure.  This makes it clear that we are using the
right version (we weren't in all cases, in particular we weren't
recompiling the test helpers correctly.

Unless it's not available or suppressed, we might as well run it under
valgrind the first time, which speeds things a little.

We save the valgrind output file for tests_pass_valgrind's use later.

We'll need this in a moment.

There's no reason to hand in the name of the compiled _info file,
since we don't compile it up in safe mode.

Trivial cleanup, but differentiates from the general obj_list used
elsewhere.

When an open() call fails, we don't inject an error, but we didn't
apply this logic when replaying a failpath, with strange results.

This is useful for seeing where failures cause us to run slowly
(ie. we continue for a long time before terminating).

We have to be consistent with the caller, so turn on 64 bit offsets if
available for both the caller and us.

As pointed out by Christian Thaeter, it has bitrotted.

Now valgrind children report failures, this one test fails.

This is the CCAN Way.  Plus, eliminates a compile warning here.

As per the SAMBA version.

Now we can mark test files as FAIL and not be bothered by them.

For example, valgrind can't handle some things, so we may need to
switch it off, but we don't want to do that for every test.

So, start a standard format for per-file restrictions, eg:

    Ccanlint: tests_pass_valgrind test/foo.c:FAIL

For the moment, only tests_pass_valgrind takes options, so it has to
change: we now have a helper which returns the array of options
applicable to a given file.

Valgrind notes that our child processes leak memory.

We turned on --child-silent-after-fork=yes, because the output
confused our dumb parser.  Now we split output by prefix ("==<pid>==")
and then we can sort out the leaks from the errors.

This means we find more errors.... next patch!

Our own dogfood, and it's yummy!

Simplifies future patches.

Memory leak in tests revealed bug in jmap_free.  Also, out-by-one
error.

We can only test the featureless tests, once we've built them!

layout.c's TDB creation functions were incorrect in case of a hash
collision, causing occasional failure.  Make it always use the
(previously-failing) seed value, and fix it.

It's just a header, I don't care what's done with it.