Useful routine to count number of matches in a string.

A bit more awkward, but more consistent with everything else.

Since test keys are used for --target=, this is useful.

Joey Adams also pointed out that we should use strings for the dependency
lists.  Moving them into the structure also somewhat simplifies it.

Joey Adams rightly points out that the current keys are a mess: ideally the
filenames, test keys and structure names in ccanlint should be the same.

First step is to make the test names all regular, of basic form <noun>_<verb>
(eg "tests_exist" rather than "has-tests").

This option prints the dependency graph of ccanlint's tests
in Graphviz .dot format.

Sample usage:

ccanlint --test-dep-graph | dot -Tpng > out.png && eog out.png

These tests:

	"depends-exist"      (compulsory_tests/check_depends_exist.c)
	"info-documentation" (tests/has_info_documentation.c)

used m->info_file without checking if it was NULL,
leading to a segfault when no _info file was present.

Some other tests also used m->info_file without depending on "info",
but are taken care of indirectly by this patch.

&*ptr is used in some other macros, but at a glance, they look like
cases where the pointer shouldn't be NULL .  Didn't change those,
and if we get more warnings, we'll cross that bridge when we get to it.
For now, I suppose they are just free NULL checks.

The parenthesized thing is confusing and ccanlint dislikes it.

There are a large number of BSD variants out there, be explicit.

The upcoming failtest module can only tell that a child failed when it
exits with a non-zero error.  So we need this, although it means for ccanlint
it still needs to look at output to distinguish a memory leak from a real
error.

If an example #includes <ccan/foo/...> we assume it needs module foo,
but we would fail instead of building it if it isn't built.

As we start doing more building of dependencies, this saves us effort.

I chose not to do the "macro creates set of routines" approach, as
we can be almost as safe with a struct containing a pointer to the member
type.

I find hiding the declaration in LIST_HEAD() a bit weird.

In particular, we test the corruption cases.

Deletion from a specific list.

When CCAN_LIST_DEBUG was defined, we were previously calling
list_check() in list_del instead of list_check_node(), which caused a
warning.

We also should stick within the "list_" prefix namespace, so rename
"debug_list" to "list_debug".

We lose the histograms, but this prepares it for upstream merge.

One free record is not "uncoalesced".

Remove code duplication, and allow unit tests (which #include both).

Test compiled with warnings:
/home/rusty/devel/cvs/ccan/ccan/typesafe_cb/test/compile_ok-typesafe_cb-NULL.c:/home/rusty/devel/cvs/ccan/ccan/typesafe_cb/test/compile_ok-typesafe_cb-NULL.c: In function ‘main’:
/home/rusty/devel/cvs/ccan/ccan/typesafe_cb/test/compile_ok-typesafe_cb-NULL.c:18:2: warning: taking address of expression of type ‘void’
/home/rusty/devel/cvs/ccan/ccan/typesafe_cb/test/compile_ok-typesafe_cb-NULL.c:18:2: warning: taking address of expression of type ‘void’
/home/rusty/devel/cvs/ccan/ccan/typesafe_cb/test/compile_ok-typesafe_cb-NULL.c:18:2: warning: taking address of expression of type ‘void’
/home/rusty/devel/cvs/ccan/ccan/typesafe_cb/test/compile_ok-typesafe_cb-NULL.c:18:2: warning: taking address of expression of type ‘void’
/home/rusty/devel/cvs/ccan/ccan/typesafe_cb/test/compile_ok-typesafe_cb-NULL.c:18:2: warning: taking address of expression of type ‘void’
/home/rusty/devel/cvs/ccan/ccan/typesafe_cb/test/compile_ok-typesafe_cb-NULL.c:18:2: warning: taking address of expression of type ‘void’
/home/rusty/devel/cvs/ccan/ccan/typesafe_cb/test/compile_ok-typesafe_cb-NULL.c:18:2: warning: taking address of expression of type ‘void’
/home/rusty/devel/cvs/ccan/ccan/typesafe_cb/test/compile_ok-typesafe_cb-NULL.c:19:2: warning: taking address of expression of type ‘void’

If they specify valgrind options in their _info, we should use them when
running with --db-attach=yes, too.

This is complicated by valgrind's limited options, and our desire not to run
valgrind twice (it's already the slowest part of the tests).

Ideally I'd like a different error code for each kind of error.  I
could parse and pretty-print the XML output, but instead I just parse
the human-readable (which is fragile).

It requires that we build the objects first.