Before this change, refs would be stripped from documents by default
(even documents, such as invoices, that don't normally have any
explicit YAML head).  After this change, refs are not stripped by
default, but if you put "remove-refs: TRUE" in the YAML head then they
will be, and you can optionally customize the regex with "ref-regex".

Note also that it's "ref-regex" now instead of "ref_regex".  This is
because some editors (cough Emacs cough) render unescaped underscores
in a jarring and distracting way in LaTeX documents, including even
underscores in YAML frontmatter.  A better fix would be to teach Emacs
how to recognize when it's in a non-LaTeX section of a mostly-LaTeX
document, but that's a bit more yak than I have time to shave today.

Before this fix, building a document that has zero instances of
"\VAR{todo('foo')}" in it would still result in a "No todos" message
at the top (this has probably been true since commit 5a765ff9).

This is how our infrastructure improves, one yak-shave at a time.

Make "hour" and "hours" align on the right, which visually implies a
vertical line between the hours column and the charges column.  This
in turn makes right-aligning the charges column even more attractive
than it already was, so do that too (though it was probably a good
idea before and we just hadn't gotten around to doing it until now).

Persuading LaTeX (or rather, TeX) to vary its output based on singular
vs plural turned out to be a major research project.  But now we've
finally done it, so we can just sit back and let the profits roll in.

Since the OTS_DOCTOOLS_DIR environment variable is required now, use
that instead of Python's '__file__' variable to get values for the
YAML block comment that we put at the end of each PDF.

Note that the two other uses of '__file__' in this code base, in
'pipeline/pipeline.py' and 'pipeline/plugins/65_bugs.py', stay as they
are: for what they're doing, '__file__' is appropriate.

Before now, building "foo.pdf" would instead build "foo-rREVNUM.pdf"
(where REVNUM is determined by 'get_revision') and symlink "foo.pdf"
to that.  Although this had its uses, it also would occasionally cause
problems, primarily accidentally copying the symlink to somewhere else
and ending up with a broken symlink at the destination.  After
discussing it yesterday, James and I decided to switch to the simpler
"just build foo.pdf" method, and that's what this commit does.

The former supersedes the latter, and has more options, so we should
use it.  But the proxemitae cause for this change is that I wanted to
use lower-case Roman letters as item markers instead of numbers.  Now,
you might think it would work to just put "\usepackage{enumitem}" at
the top of the doc and then use "\begin{enumerate}[label=\alph*)]",
but no, that gets an error:

  ! Missing number, treated as zero.
  <to be read again>
                     \c@*
  l.394 \begin{enumerate}[label=\alph*)]

  !  ==> Fatal error occurred, no output PDF file produced!

The reason for this is that the two packages are incompatible.  With
'enumerate' already loaded, if you load 'enumitem' and then try to
take advantage of the feature for which you brought in 'enumitem' in
the first place, you'll get the above error.

This change should not break any of our older documents, since both
packages work fine for plain old enumerations or lists, and until now
that's all we could do -- we obviously weren't using the list-item
styling feature that 'enumitem' makes possible.  I also spot-checked
several of OTS's more complex documents to make sure they still build.

Adjust where the date sits under the signature, so that the date isn't
squashed down such that it touches the hrule line underneath it.

Context: I actually made this change on November 3rd, as part of
building a contract document that day.  However, I forgot to push the
change then, and later it was in the way when I needed to pull from
upstream.  Rather than create a merge commit, I just saved the patch
and re-applied it.  So if you're at OTS and you're wondering about the
motivation for this change, look for a contract build on 2020-11-03.

This follows up to r16468 in the corporate repository.

At least right now there is a moment in Debian 'testing' in which
there is no 'python' command, only 'python3'.  Since we are already
explicitly finding 'python3' for PYBIN anyway, just use that.

I actually wrote this up on May 7th, but forgot to commit it.