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.

In https://github.com/OpenTechStrategies/ots-doctools/pull/10,
@choeppler points out (#pullrequestreview-425924575) that the "OTSDIR"
environment variable should not be required to be set, since only
"OTS_DOCTOOLS_DIR" is documented, and that furthermore if we are going
to check paths under "OTSDIR" we should at least do it in the same
order relative to "OTS_DOCTOOLS_DIR" that 'Makefile.docspecific' uses.

This commit is his suggested patch from that PR review.  (Note that
the commits in that PR are actually already applied.  There must have
been a rebasing somewhere along the way, as they all have different
commit IDs in master than they do in the PR.)

I don't actually use the venv, and I was tired of it littering.
Virtual environments are probably best left to the user to configure,
and not for us to force on the user.  It's still nice to have it as a
backup, but if the user has a way to satisfy those dependencies
without our intervention, don't intervene.

There are a few ways to supply the python submodules that aren't in a
local venv.  One might install systemwide, use direnv, or use a
centralized venv for all of ots, etc.  I use direnv, but this change
makes room for any scheme a user might want.  We force our own venv
only as a last resort.

Explain what reference system we're using in case somebody else is
interested in the plugin.

  * Detect inkscape version of 1.0 rc 1 or later and add some tex to
    call inkscape using new-style command line parameters.

  * Add a preambles loop to the base jinja template so we have an easy
    way to add preamble sections that doesn't require clobbering the
    existing preamble items

  * Add a dump function to pipeline.py so we can dump our output and
    inspect it during debugging.

As promised in commit db47b65d.