I don't imagine that we would ever include this header by itself,
so there's no real need for it to be compile-able by itself.  But
I figure there's no harm in fixing it.

This should have been part of:
    2018-12-10 monoclock: add timeval_diff()
    7c958f46ab600d1d63728eaf73822cf51d7d3b8b

This fix allows us to use it with `struct timeval * foo` pointers.  And
it's also safer to use parentheses for all uses of arguments in macros.

This is just like
    2016-01-17 Silence warnings re unused declarations in macros
    909f3f5871eb5f184fb82c38c832ae09cd15960e
which did this for cpusupport.h and elasticarray.h

Previously, we could write
    MPOOL(foo, int, 0);
which would expand to
    static void * mpool_foo_static[0];

An array declaration with fixed size 0 is not allowed in C99:
    6.7.5.2 Array declarators
    ...
    If the expression is a constant expression, it shall have a value
    greater than zero.

gcc complains about such an array, but clang doesn't.

Even if we ignore the zero-size array, the above would also expand to:
    static struct mpool mpool_foo_rec = {0, 0, ...

which would set M->allocsize = 0.  That would result in malloc(0) being
called inside mpool_free(); also, mpool_free() would be unable to
increase the size of the pool since that code relies on doubling
M->allocsize.

M->allocsize is non-zero to begin with, but theoretically if it started
as a power of 2 and we kept on doubling the pool, it could wrap around
to 0 again.  Of course, we would run out of memory long before that
actually occurred.

A more concrete benefit is that some static analysis tools don't realize
that M->allocsize > 0 (despite adding the CTASSERT in the previous
commit), so they warn about a potential malloc(0) in mpool_free().  This
eliminates those spurious warnings.

Reported by:	clang-tidy