Like perhaps any Lisp, the build process for glotawk is slightly
convoluted.

First, the code is split into several AWK files, but for ease of
execution, glotawk should be a single file. This is why tmpl.awk was
first made, and supports @include directives.

Second, the built glotawk file should be executable, and should run
with the correct awk implementation; thence the @shebang directive.

There are many special forms; these are only treated specially when
they occur in operator position. To use them as higher-order
functions, they must be bound as values. The most concise and
maintainable way to do this is to write trivial definitions in glotawk
Lisp (lib-eval.awk); but that makes startup time unbearably slow. So
dump.awk supports dumping the AWK data structures that are built up
when things are defined, out to (inscrutable) AWK code that directly
(and quickly) reconstitutes them. We construct glotawk-build.awk
including that slow code, then dump an image using ~(dump
"image.awk")~, then build the glotawk intended to be run including
that image rather than lib-eval.awk. The two are quite similar, and
will need to remain so through many changes yet to come; and this is
why the multi-level includes and glotawk-common.awk were added.

Finally, when any source file is changed, the things that should be
built are the things that included it, but the means of inclusion is
tmpl.awk, of my own devising; therefore the means of turning those
includes into statements to make of dependencies must also be of my
own devising. And that's why the @target directive exists, and the
reason for tmpl-depends.awk. This constructs a .depends file which
make reads.