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.

NOTE: btree was originally copyright 2010, and has not been
touched by me since then.  I don't know if changing the license
to something more permissive requires updating the copyright year
or not.

NOTE: block_pool was originally copyright 2009, and has not been
touched by me since then.  I don't know if changing the license
to something more permissive requires updating the copyright year
or not.

No point checking malloc failure in usage(), since we don't elsewhere.
We get 100% coverage with -O (due to code elimination) or 64 bit.

In particular, handing an pointer to ULL where a pointer to UL is expected
won't work on big endian.

As with the set_ functions, there are twelve permutations of integer size,
base, and signedness.  The supported sizes are int, long, and long long.

For example, this:

 char buf1[OPT_SHOW_LEN];
 char buf2[OPT_SHOW_LEN];
 unsigned i = 1024000;
 opt_show_uintval_bi(buf1, &i);
 opt_show_uintval_si(buf2, &i);

will put "1000k" in buf1, and "1024k" in buf2.

Unlike the opt_set_ functions, these use unsigned arithmetic for unsigned values.

(32 bit bug using sizeof(suffixes) instead of strlen(suffixes) fixed by Rusty)

This comment occurred in a couple of places:

 /* Set an integer value, various forms.  Sets to 1 on arg == NULL. */

One instance was clearly spurious, while the other was misleading.

Another resolution to this mismatch would be to add
"if (arg == NULL){*l = 1; return NULL}" somewhere, but I suspect
it may have been left out/removed because someone thought better.

These functions come in two flavours: those ending with "_si", which
have 1000-based interpretations of the suffixes; and those ending with
"_bi", which use base 1024.  There are versions for signed and
unsigned int, long, and long long destinations, with tests for all 12
new functions.  The tests get a bit repetitive, I am afraid.

As an example, if the -x option were using the opt_set_intval_bi
function, then all of these would do the same thing:

$ foo -x 5M
$ foo -x $((5 * 1024 * 1024))
$ foo -x 5242880
$ foo -x 5120k

quite what that thing is depends on the size of your int -- people
with 16 bit ints would see an "out of range" error message.

The arithmetic for unsigned variations is actually done using signed
long long integers, so the maximum possible value is LLONG_MAX, not
ULLONG_MAX.  This follows the practice of existing functions, and
avoids tedious work.

We were missing failed tests: if the top-level returns FAIL_PROBE, we would
exit; this should only apply to children.