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

... demonstrating that the PRIV_* states are per vmod, no matter if accessed
from a function or method

Fixes #1800

part of #2061

Part of #2061

Related to #2025.

With input from nigoroll.