r2640: valgrind does a great job on some types of memory leaks, but is slow

r2640: valgrind does a great job on some types of memory leaks, but is slow
and can't properly handle leaks of doubly linked lists which we use a
lot (as the memory is always reachable). Even with --show-reachable
its hard to track leaks down sometimes.

I realised that talloc does have the necessary information to track
these, and by using the cascading property of the new talloc it can
report on leaks in a much more succinct fashion than valgrind can.

I have added a new samba option --leak-check that applies to all Samba
tools. When enabled it prints a leak report summarising all top level
contexts that are present when the program exits. A typical report
looks like this:

talloc report on 'null_context' (total 1071 bytes in 52 blocks)
        iconv(CP850,UTF8)              contains     43 bytes in   3 blocks
        UNNAMED                        contains     24 bytes in   1 blocks
        UNNAMED                        contains     24 bytes in   1 blocks
        dcesrv_init                    contains    604 bytes in  26 blocks
        server_service                 contains    120 bytes in   6 blocks
        UNNAMED                        contains     24 bytes in   1 blocks
        UNNAMED                        contains     24 bytes in   1 blocks
        server_service                 contains    104 bytes in   4 blocks
        server_context                 contains     12 bytes in   2 blocks
        iconv(UTF8,UTF-16LE)           contains     46 bytes in   3 blocks
        iconv(UTF-16LE,UTF8)           contains     46 bytes in   3 blocks

the numbers are recursive summaries for all the memory hanging off each context.

this option is not thread safe when used, but the code is thread safe
if the option is not given, so I don't think thats a problem.
(This used to be commit 96d33d36a5639e7fc46b14a470ccac674d87c62a)