Change CLI cmd debug.xid to set the next XID to be used, rather than "one less than the next XID to be used"

Opportunity noticed during the review of #3872.

This is an enhanced fix for #1777

Fixes #3882

Otherwise a long banner may throw expectations off by one line.

Fixes #3877

Neither Martin nor I can remember why this was uintptr_t in the first
place, and there is no signs of pointers anywhere nearby.

Refs #3874

It makes no sense to emit this just before we end the transaction,
except to help varnishncsa find the client IP address.

Upon success we expect a non-null pointer, and to make sure this is not
residual uninitialized stack memory, it is null'd beforehand.

    /bin/varnishd/cache/cache_acceptor.c: 375 in vca_mk_tcp()
    369     {
    370             struct suckaddr *sa;
    371             ssize_t sz;
    372
    373             AN(SES_Reserve_remote_addr(sp, &sa, &sz));
    374             assert(sz == vsa_suckaddr_len);
    >>>     CID 1517259:  Resource leaks  (RESOURCE_LEAK)
    >>>     Failing to save or free storage allocated by "VSA_Build(sa, &wa->acceptaddr, wa->acceptaddrlen)" leaks it.
    375             AN(VSA_Build(sa, &wa->acceptaddr, wa->acceptaddrlen));
    376             sp->sattr[SA_CLIENT_ADDR] = sp->sattr[SA_REMOTE_ADDR];

It is precisely because we reserve the space to store the built suckaddr
that there won't be a malloc() call made behind our back.

For some reason, it only complained about one call site.

Inspired by: CHERI

Spotted as always: by Dridi