This worked only because REQ_BODY_INIT = 0

I hate C enums.

This reverts commit 54e7d45b.

However instead of reverting to the previous domain, I picked a
different one that I hope will not turn out controversial.

This is a result of a commit review between 6.2.0 and 6.3.0 and while
it should in theory be comprehensive, it is not. The upgrade notes in
particular are developer-centric, which may be a sign that none of the
changes require attention during an upgrade it could as well be an
oversight.

There is one item that I identified that should be mentioned in the
upgrade guide. I invite @nigoroll to give a shot at the VCL auto state.

In the absence of a fair warning, I extended WS_Reserve's grace period.

I omitted the -rcvbuf action on purpose, for the same reason why it is
not documented in vtc(7) on purpose: it's currently used in conjunction
with vmod_debug and we don't ship it.

While this is a milestone, I don't consider this work to be done so I
didn't remove the notes saying so.

We should also probably partially pick 53b4d2f5 on the 6.3 branch.

The Keybindings section is the only place mentioning differnt log levels
and one might assume that `-1` or `-j` behave the same as the default
ncurses interface.

The latter however does not show all counters by default as the single
action flags do, hence `varnishstat -f '*overload*'` will not show
`MAIN.sc_overload` by default, with `-1` however it does.

Fix grammar while here.

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

They are however far from complete, and that's an UNDERSTATEMENT.

C-spec to understand what the SunOS compiler was whining about.

Strictly speaking it has a point, code is different from data is
different from const data, so mixing pointers the way we did was
not kosher.

We probably should have made the identifying argument a uintptr_t
instead of const void* to begin with to deal with this.

This reverts commit 2034138e.

We already know that SunCC will complain about those. Alternatively we
could use static variables addresses as cookies, but do we need extra
symbols?

Refs #3184

You never know what the next test case will look like...

Apologies, I wrote this one to have proper coverage of priv_call->free
functions, and the assertions free_re contains. I forgot to add it to
the commit...

This is in essence the same VMOD so migrating from one to the other
should result in no VCL change, except for the removal of DEPRECATED
cookie.filter_except().

The test suite was refreshed to take advantage of recent features and
mostly operates in vcl_synth as a result, not wasting cycles bringing
needless backends up.

The C code and VCC descriptor were also improved for better code style
compliance and documentation consistency, without changing the VMOD's
behavior. On the C side actual changes mostly consisted in adding missing
assertions but there were notable changes:

- usage of VRE_Free instead of free (with test case)
- WS_VSB_* facility usage for the one use case

There are other opportunities for improvement, like usage of more modern
facilities like VRT_fail, or a named Lck instead of a plain mutex.

Closes #3184

or rather: fail the task if being rolled back

I forgot the namespace when I first split the test suite.

We only need the @VTC_TESTS@ substitution, and doing so saves around
13kB per Makefile.

That part of the automake boilerplate is generated conditionally, and
since we check automake_boilerplate.am files in the list of tests is
printed with one per line to be diff-friendly.

A test was "randomly" chosen to be the first VMOD-specific test.

Generated automake_boilerplate.am files no longer start nor end with
empty lines.

This is probably going to mandate some changes in vtest to collect
VMOD-specific test suites.

Refs #3184

The effect is currently the same, but for VMODs we shouldn't need a
complete configure step.

Refs #3184