on the workspace to check if any element of it is non-NULL.

Spotted by:	Steven

Spotted by:	fgs & ubsan

Instead of a timestamp per line, which makes diff(1) really hard
to use, emit millisecond timestamps on separate "dT" lines, whenever
time has changed since last timestamp.

so we apply it only where it makes most difference.

The hard work done by:	slink

Closes: 2792

That libtool bug on SunOS...

Spotted by VTEST.

This would trigger the tautological-compare warning on a recent-enough
Clang, and SunCC appears to complain as well.

Reported by @daghf.

Restructured so that:

* 'Upgrading' is limited to work that has to be done to upgrade from
  a current deployment to the new version.

* 'Changes' is a comprehensive, user-level description of changes and
  new features.

Conflicts:
	doc/sphinx/whats-new/index.rst

Forcing one line per query can lead to very long lines for cases where
we can't decompose OR-able individual queries. Where newline previously
acted as a mere space between tokens, the backslash-newline sequence now
fills that void.

Not a multiline VSL query, it's the record containing multiple lines.

This makes the following queries equivalent:

    vut -g request -q '*Error' -q 'BerespStatus >= 500'

    vut -g request -q '
        *Error
        BerespStatus >= 500
    '

    vut -g request -q '(*Error) or (BerespStatus >= 500)'

We now have two ways to express "compound" VSL queries, although this
ultimately relies on multiline queries.

The two following queries now become equivalent:

    vut -g request -q '
        # catch varnish errors
        *Error

        # catch backend errors
        BerespStatus >= 500
    '

    vut -g request -q '(*Error) or (BerespStatus >= 500)'

It becomes interesting when we wish to capture transactions for
different scenarios but would like to decompose them cleanly.
Especially when the query of an individual scenario is rather
complex and OR'ing everything manually would become cumbersome.

This diff is better viewed with the --ignore-all-space flag.

We always add tokens in order, we don't need to check whether there was
one present in the first place.

Now that we can have multiple lines in a query, it may come in handy to
add a description of a query or its purpose.

Instead of treating it as a mere whitespace separator. As a result the
lexer output looks like this:

    TOK_1, ..., TOK_N, EOI[, TOK_1, ..., TOK_N, EOI[...]]

At this point though, only the first series of tokens is considered, in
a single query mode that was already what we've had so far. It will also
be the parser's job to ignore consecutive EOI tokens for "empty" queries.

We have a dedicated enum entry for that, and nothing prevents the caller
from passing a negative value.