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.

how vcc_expr actually works...

No methods are implemented yet.

get too confusing.

background: When the ban lurker has finished working the bottom of the
ban list, conceptually we mark all bans it has evaluated as completed
and then remove the tail of the ban list which has no references any
more.

Yet, for efficiency, we first remove the tail and then mark only those
bans completed, which we did not remove. Doing so depends on knowing
where in the (obans) list of bans to be completed is the new tail of
the bans list after pruning.

5dd54f83 was intended to solve this,
but the fix was incomplete (and also unnecessarily complicated): For
example when a duplicate ban was issued, ban_lurker_test_ban() could
remove a ban from the obans list which later happens to become the new
ban tail.

We now - hopefully - solve the problem for real by properly cleaning
the obans list when we prune the ban list.

Fixes #3006
Fixes #2779
Fixes #2556 for real (5dd54f83 was
incomplete)

93d80501 made execution of
ban_lurker_test_ban() conditional on bd != b, which effectively caused
objects hanging off bans below request bans to not get tested against
relevant bans.

Because object bans (from the obans list) are being marked completed,
the objects which were skipped would also be missed to get evaluated
against the relevant bans at lookup time unless they were evaluated in
request context. So, in effect, we would simply miss to test bans.

Fixes #3007

Maybe related to #3006