make our AtomicCounter 64 bit on 64 bit machines
Our "StatBag" statistics class was 1) 32 bit 2) heavily locked 3) still allowed for lock-free operations for high speed counters.
This commit 1) makes the StatBag 64 bit on 64 bit systems, 2) removes all locks and 3) has gone AtomicCounter 'native'
The upshot of this is that 64 bit users will suddenly get 64 bit counters. A second upshot is that multicore systems should now see consistent statistics again.
One important thing that changed is that the StatBag class used to be completely thread safe, and now it no longer is. You can't declare new counters while the StatBag is in use. This should not be happening, but you never know.
Finally, there is now a StatBag unit test.
actually writing some unit tests for the new 64 bit capable AtomicCounter found a pile of bugs!
a 32 bit regression test failure we don't understand..
this should fix our unit tests
disabling test if test environment does not define things we need to know..
split up the packet & query cache into 1024 shards so our locks no longer collide

Conflicts:
	pdns/packetcache.cc
speed up the testbag test a bit (by doing smaller tests)
add unit tests for new sharded packet cache
make sure we lock the cache shards while we clean them, closing #1910. Plus add regression test that pretty reliably
detects us not locking.
add a bunch of packet based regression tests to the packetcache
fix up our packet cache unit tests plus add bunch more tests
enable callback based metrics to statbas, and add 5 such metrics: uptime, sys-msec, user-msec, key-cache-size, meta-cache-size, signature-cache-size
fix up statbag for carbon protocol and function pointers
make latency & qsize reporting 'live'. Plus fix that we only reported the qsize of the first distributor.
mind04 discovered we count corrupt packets and EAGAIN situations as validly received packets, skewing the udp questions/answers graphs on auth.
don't do time(0) under signature cache lock
add signatures metric to auth, so we can plot signatures/second
make qsize-q more robust
add 'bench-db' to do very simple database backend performance benchmark