Not sure I like that everything is a bullet point, but well, someone
else did the dirty work for this release so I'll shut up and roll with
it.

We are finding more flaky tests thanks to them, so for now we prefer to
avoid false positive over slowing down the build.

have seen this failing on Travis with:

**** v1   vsl|       1004 VCL_call        b BACKEND_FETCH
**** v1   vsl|       1004 VCL_return      b abandon
**** v1   vsl|       1004 BereqAcct       b 0 0 0 0 0 0

Tested ok locally with varnishtest -n 1000 -j 60.

As @Dridi rightfully commented via email, the default vsl_mask does not
contain Debug

no, they do not need a Translation Lookaside Buffer

Closes #3237

Refs 0cf29671

Automated with Coccinelle, so the semantic patch could be reused in the
vtest project.

Closes #3238

This reverts commit ac602e01.

@Dridi reminded me that we do not want "trunk" release notes in the 6.4
branch to come.

I went through changes.rst and carried all aspects over to the release
docs which I considered relevant.

Please feel free to polish, I will not be able to get back to this today.

sorry, the previous commit probably broke building the docs

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

The refcount of the vcl can also have gone down to zero as in this vtc
output:

**   top  === process p1 -write "vcl.li\t\r"
**** p1   Writing 8 bytes
**   top  === process p1 -expect-text 0 1 "active   auto    warm         1...
**** dT   2.143
**** p1   output|varnish> vcl.list
**** dT   2.173
**** p1   output|varnish>
**** p1   output|
**** p1   output|200
**** p1   output|active   auto    warm         0    vcl1
**** dT   2.212
**** v1   vsl|          0 CLI             - Rd vcl.list
**** v1   vsl|          0 CLI             - Wr 200 40 active   auto    warm         0    vcl1

As the process facility does not support regexp-expects (yet?), we just
check for the beginning of the line

fix signed/unsigned comparisons

Spotted by vtest on SunOS.

b365be2d was not correct in that I put
vcc_compile.h in the wrong place, it should have been added to GEN_H,
not as a dependency for GEN_H

I also realized that we should wait for the last file generate.py
generates.

It remains a private static library. Neither libvarnishapi nor test
cases from libvarnish use individual source files besides the ones
containing test drivers.

It can lead to very cryptic messages where a symbol is defined twice
from different sources, where the sources are the same but the object
code is technically different (a copy built from _SOURCES and a copy
in libvarnish.a).

While at it, add sanitizers flags to all libvarnish test cases.

It can definitely be used in third party VMOD projects.

vcc_compile.h is generated and included by other compilation units, so
we need to make sure that this happens in sequence.

Seen on vtest:

make[5]: Entering directory
'/tmp/vtest.32_sun12.4/varnish-cache/lib/libvcc'
  CC       libvcc_a-vcc_acl.o
  CC       libvcc_a-vcc_action.o
  CC       libvcc_a-vcc_backend.o
  CC       libvcc_a-vcc_backend_util.o
  CC       libvcc_a-vcc_compile.o
  CC       libvcc_a-vcc_expr.o
mkdir -p ../../include/tbl
/opt/local/bin/python3.4 ../../lib/libvcc/generate.py \
    ../.. ../..
  CC       libvcc_a-vcc_parse.o
  CC       libvcc_a-vcc_storage.o
  CC       libvcc_a-vcc_symb.o
"vcc_compile.h", line 194: undefined symbol: VCL_RET_MAX
"vcc_compile.h", line 194: can not declare variably modified type at file scope
cc: acomp failed for vcc_parse.c
Makefile:668: recipe for target 'libvcc_a-vcc_parse.o' failed

it seems I wrongly assumed that SIZE_MAX would be defined as a positive
integer, in fact it looks like (size_t)-1 was used.

Ref: 2d890940

Have seen ExpKill interfere with the Debug messages in vtest

The great witness test introduced by @bsdphk and reworked relatively
recently by @Dridi reported a hypothetical lock cycle here.

This was not a real issue, because the scheduling code would not re-enter
the probe code, yet we might still drop the probe lock while
scheduling.