Fixes: #2086

Big thank you to fgs for the rest of the spell correction!

Fixes #2022

... which is what we've done all along, but weren't aware of, until
clang with specific compiler flags exposed the issue.

The local declaration of crc32 on shard_hash.c is hackish, but
it appears we'd need to include almost all of the libvgz includes
otherwise.

Huge thank you to phk for helping track down this odd issue.

The gotos are an integral concept of the code gen to produce code which can
be compiled efficiently. We could hand-craft it for the purpose at hand,
but I don't see much value in that.

This reverts commit 4a5ec60a.

We should have interpreted it as big endian right from the start,
but now that we got the existing code developed on little endian,
we keep it so.

- rename struct vmod_shard_shard -> vmod_directors_shard
- rename typedefs td_shard_* -> td_directors_*
- documentation reformatting
- remove vbe32dec copy
- include generated shard_parse_vcc_* files because enum parse code
  generation should be included in vmodtool, if at all (do not want
  an additional build dependency to perl)
- make key function a method

Source:

https://code.uplex.de/uplex-varnish/libvmod-vslp/tree/shard
0f8c3f0f52ca9911d4aed0ce5faf203ab7ff26b0

Follow-up 9095c5cf

Belongs to #2057

Follow-up 9095c5cf

Belongs to #2057

Downstream packages can always replace it with a different version.
End-users can override it in their `/etc` tree.

By default: /usr/share/vcl

This directory becomes a drop-in, and standard location for library-like
VCL files. It streamlines third-party VCL packaging, offering a blessed
for installation, leaving the canonical /etc/varnish directory entirely
to the end-user.

While it is common to see VMOD packages in the wild, there are some VCL
libraries (sometimes backed by VMODs) that would benefit some form of
standardization. It then becomes possible to install packages, and use
relative includes that JustWork(tm). This is especially true for VCL
libraries that are split into several files, they can put themselves in
a subdirectory in /usr/share/vcl and use it as a namespace for includes
between files of the library:

    # somewhere in my awesome "foo" library
    include "foo/some_feature.vcl"

Choosing a default path of `/etc/varnish:/usr/share/vcl` prevents VCLs
dropped in the system from shadowing end-users VCLs but at the same
empowers said users to override a "standard" VCL in their `/etc` tree,
with no additional parameters fiddling.

Follow-up 9095c5cf

Belongs to #2057

E.g. set req.http.foo = req.http.foo + req.http.bar ~ "foobar"

Noticed that I've been missing this since the beginning of time when
porting some ancient inline-C.

We already have obj.uncacheable und obj.hits in vcl_deliver, so not
having these seems arbitrary. Copying out the values in vcl_hit just
to have them available in vcl_deliver, as it was possible previously,
implies unnecessary overhead.

One use case is to extend object lifetime downstream when delivering a
stale object, e.g.

sub vcl_deliver {
    if (! obj.uncacheable && obj.ttl < 0s) {
	set resp.http.Expires = now + 1m;
	set resp.http.Cache-Control = "public, max-age=60";
	unset req.http.Age;
    }
}

merges #2057