make: fix dirty check, support concurrent build

[wilhelmtell]

if we hardwire the build script in the target commands, then what we
want to do remains opaque to make. it is better to speak make's
language, so it understands us, so we can rip the benefits from that.
really, we don't have 1 test target, but we have 3 targets: the 3 pdf
examples.

when we extract 3 rules from the 1 we have right now, make gets to
understand what we actually want to do:

• understand there are 3 steps to the build, not 1
• understand what are the products that will yield (pdfs)
• understand products' dependencies (texs)
• understand the products are independent of each other

when make knows what the products are and their dependencies are, it can
tell when there is no work to do. for example, if the pdf is already
there and its tex dependency hasn't changed, there is no need to
re-compile the pdf.

when make knows the products are independent of each other, and we
compile with make -j, then it can do a faster build by compiling the
pdfs concurrently, rather than serially one after the other.

there is an additional benefit here: we can compile a particular pdf,
and not the others: make examples/cv.pdf.

finally, note that because now make can tell when there's nothing to do,
you might be surprised if, for example, on a pristine checkout of the
repository, you run make, and make responds

make: Nothing to be done for `examples'.

this is because the pdfs are checked in, and make sees the texs haven't
changed since they were last compiled. to force a build as was the case
before, run make -B. alternatively, you can touch any of the tex files,
and make will recompile the touched texs.

[wilhelmtell]

Is this repository active?

[posquit0]

Sorry for my late response.
If you make your pull-request again, I'll apply ASAP. I think your suggestion is good 👍

[wilhelmtell]

I lost my changes..

I re-created the commit. The sha is different though, so maybe I need to create a new pull request?