Ref #1799

In order to avoid the cross product problem with conversion functions
(from x to y types would require x*y functions), we add flexibility
regarding the input parameters to conversion functions:

Each convertion function named after the destination type now takes all
sensible arguments by name.

int is named integer because of the reserved symbol name "int" in C.

All functions should be fully backwards compatible (existing vtcs
continue to work), but compile time checks are now effectively removed.
The conversion functions now trigger vcl errors if used incorrectly or
if conversion errors occur and no failback is provided. However, if a
failback is provided, vcl errors are only raised for usage errors.

For consistency, the conversion functions now only ever truncate if
necessary. std.round() is added for explicit rounding where required.

Existing functions which are now obsolete are marked deprecated.

Ref #2899
Ref https://github.com/varnishcache/varnish-cache/wiki/VIP12:-vmod-polymorphism-(for-type-conversions)

I have reimplemented this based on Nils's #2858, because I found
it too complex and intrusive.  (In particular we try to avoid
unions in Varnish).

Testcase m00051 by:	Nils Goroll

Closes:	#2858

It may have sounded like it's been added for the first time.

the previous code would round 9007199254740991 to 9007199254740992

Tested on linux and the four vtest SunOS variants

vtest would segfault due to a null pointer access on empty
headers

Closes #2905

we missed to change these when we changed the VCL_INT typedef from long
to int64_t

Should we add VCL_INT_MAX / VCL_INT_MIN (and for the other integer
types, respectively)?

Ref: doc/README.WRITING_RST.rst

in particular:

- remove defintion lists (Description/Example)
- examples as code blocks::
- argument names as *emphasis*
- ``literals``

Ref: doc/README.WRITING_RST.rst

Spotted by @lkarsten

This commit attempts to make it easier to read build output, and
hopefully makes configure.ac easier as well.

-Wall has already been added around line 645, no need to add it twice.

On GCC -Wreturn-type is a part of -Wall, which we enable elsewhere.

    https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html

On Clang -Wreturn-type is enabled by default:

    https://clang.llvm.org/docs/DiagnosticsReference.html#wreturn-type

Same with -Wswitch as -Wreturn-type, so that can be removed as well.

Finally, use spaces instead of tabs to make cc output shorter and more
readable.

I did consider generalizing VCL_IterDirector which handles backend
iterations for the CLI, but found the complications not worth the
savings for such a trivial function.

Thank you, @Dridi

- yes, allocations outside the lock were motivated by minimizing the
  critical section, but n_backend could actually change, so this was
  wrong. As we use an RW lock, doing more work under it should only have
  marginal impact.

- n_backend == 0 is probably best handled as a special case

With that, (almost) only libvgz carries goto statements from zlib.

This isn't changing any of the previous semantics, in particular the
AN(be) assertion from the "ok:" jump is honored by all code paths
formerly leading to it.

Previously, the bitmap was allocated on the stack prior to the magic
check of shardd, which is now fixed at the expense of a potential code
style violation. But more importantly, we currently read the number of
backends prior to acquiring the read lock, but there is no evidence
that this was done on purpose and not overlooked, besides moving a
possibly expensive state initialization outside of the critical
section.

If that was on purpose, please document it.

References #2912

things I seem to only notice in my email reader...

Previously, we did not test for the storage being actually freed and
freeing only happened for passes, either explicit or a hit on hfm or
hfp, but not the for the object becoming the hfm/hfp.

We now handle incremental freeing for hfm/hfp as for private objects and
add a test which actually checks that storage is being freed on the go.

Fixes #2653

also polished http_swallow_body() and made the body dump prefix name
more consistent to indicate the receive method:

	(new)		(old)

	chunked		body
	c-l		body
	eof		rxeof

per-VCL, so cleanup should only happen on the last discard event.

This brought confusion to #2576, and while that ticket is probably
easier to debug if the counters were per-vcl, I think it is important
to keep the "per-vmod" behaviour around as an example.