This file will now contain legacy macros, that is to say shims to deal
with older platforms and macros for out-of-tree VMODs introduced with
Varnish 4.0.0-tp1.

These macros work well but their interfaces aren't ideal and they leave
too much autotools work to downstream VMOD maintainers. They have also
suffered a lack of maintenance, like this 3yo comment:

    # Uses internal function for now..

New macros will be introduced, but the current macros are left as-is and
VMOD maintainers won't be forced to upgrade their build system.

can be used for so many more things than that.

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