Fix the build and make check on 32bit platforms

[nook24]

The Debian 11/12 i386 packages build with -Werror, but make check has not passed on 32 bit for a while: two tests did not compile, which hid three failures behind them. Two of those were real bugs, not test problems.

With this PR make check passes on Debian 11 and 12 i386 and still passes on amd64.

Bugs

libnaemon replaced asprintf()/vasprintf() on every platform. configure never checked for them, so lib/snprintf.c always compiled its replacements, and libnaemon exported them ahead of libc. They are built on an old vsnprintf() that has no z, j or t modifier and, without HAVE_LONG_LONG, reads %ll as long. nm_asprintf(), nm_log() and nsock_printf() all go through it:

	glibc	libnaemon i386	libnaemon amd64
%llu;%llu	ok	second value 0	ok
%lld	ok	garbage	ok
%zd	ok	fails, returns -1	fails, returns -1

On i386 this sent SCHEDULE_HOST_DOWNTIME with an end time of 0 in test_commands. On every platform, nm_log() silently drops any message that uses %z, such as the wproc parse error in workers.c, and nm_asprintf() would exit(2) on one. Builds with -D_FORTIFY_SOURCE=2 call __vasprintf_chk() and skip the replacement, which is why the Debian packages (hardening=+all) never showed it. Unfortified builds, and NEB modules built without FORTIFY that call asprintf(), are affected. The fix adds asprintf and vasprintf to AC_CHECK_FUNCS. smb_snprintf()/smb_vsnprintf() stay exported so the library ABI does not shrink.

Timeperiod searches ran past the end of time_t. A 24x7 exclusion appears to end at every DST change. For a timeperiod that is never valid, _get_next_valid_time() therefore hops half a year at a time until max_depth. With a 32 bit time_t that goes past 2038, midnight + SECS_PER_DAY wraps to 1901, and the search returns that as the next valid time. That is a check scheduled in 1901, i.e. immediately. Both searches now stop a day before time_t runs out.

Tests

• test-bufferqueue: used unsigned long for a size_t * and %ld for size_t. It did not compile on i386.
• test-event-heap: runnable_delays held values that do not fit a 32 bit time_t, so it did not compile. event_timespec_msdiff expected an exact value where timespec_msdiff() correctly saturates a 32 bit long.
• test-arith: on overflow it asserted dest != a + b. But a + b overflows too, and the builtins store exactly that value. With a 64 bit long the branch never ran. It now compares against the long long result.

The first two commits are also part of #547, with the same SHAs, so whichever PR is merged first, the other just drops them.

Not fixed here

t-tap/test_commands fails now and then on every platform in the SCHEDULE_*_CHECK(S) next_check assertions (about 2 in 40 runs, on amd64 as well as i386). It is unrelated to 32 bit and has been left alone