The rst source has apparently become too large for gitlab web sites
to be able to render it. So we just go with markdown, in the hopes
that gitlab can better cope with it.

It's not an error if you don't have pandoc installed, but then
README will not be kept up to date with the docs in vcc.

Since 2020-06-01, backrefs fail if numbered higher than the highest
backref actually captured- Previously, re2 returned the empty string.

I believe that these tests will now pass for both current and earlier
versions.

configure checks if you have lcov & genhtml; these can be specified
with --with-lcov and/or --with-genhtml.

If they are available, then make coverage does the following:

- make clean, then make check with CC=gcc & CXX=g++, and CFLAGS &&
  CXXFLAGS set so that inputs for gcov/lcov are generated.

- lcov creates the src/coverage subdir and generates a targetfile
  there.

- genhtml generates HTML reports in src/coverage.

This necessitates adding the matchonly() method to the vre2set
interface, which only checks for matches, and does not save the
indices of matching elements. It also requires a length parameter
(since headers in struct http are not null-terminated).

It also requires the return of the configure-time check for whether
the RE2::Set::Match() method can be called with a NULL vector for
the indices.

Also update set.saved(), to enable checking if an integer was saved.

re2 no longer does that since commit
848dfb7e1d7ba641d598cb66f81590f3999a555a.

This should hopefully fix a panic which has to be caused by forgotten
WS_Release() calls and which occurred close to VCL code which handles
re2 sets.

Redacted panic:

Panic at: Fri, 05 Apr 2019 19:15:24 GMT
Assert error in WS_Reserve(), cache/cache_ws.c line 236:
  Condition(ws->r == NULL) not true.
version = varnish-trunk revision af2bad23deb2470533158f9d99ad3f4968b8d231, vrt api = 9.0
ident = Linux,3.13.0-137-generic,x86_64,-junix,-smalloc,-sdefault,-hcritbit,epoll
now = 3999664.335146 (mono), 1554491669.714933 (real)
Backtrace:
  0x43c1bb: /usr/sbin/varnishd() [0x43c1bb]
  0x49e182: /usr/sbin/varnishd(VAS_Fail+0x42) [0x49e182]
  0x45d1ac: /usr/sbin/varnishd() [0x45d1ac]
  0x44d792: /usr/sbin/varnishd(VRT_String+0x22) [0x44d792]
  0x44de66: /usr/sbin/varnishd(VRT_SetHdr+0xf6) [0x44de66]
  ...(redacted for customer proprietary information)

See also https://github.com/varnishcache/varnish-cache/issues/2967
for a general discussion regarding an inconsistency in the WS_Reserve()
interface

Ref d8ae26b5a0b4a1102360a61a145e4730e52d68bc

compile_fail.vtc evidently takes longer than 60s when run in a
docker container.

The reason is the same as for
https://github.com/varnishcache/varnish-cache/issues/2708 :

VRT_priv_task may now return NULL for out-of-workspace errors, see
https://github.com/varnishcache/varnish-cache/commit/de2b431086a13b243dc8b3e71cd8697db1df2c7f