new pkg_rr to semi-avoid python version lossage, recording python versions

[Greg Troxel <gdt%lexort.com@localhost>]

I looked at pkg_chk this morning, and concluded that long-term it's
probably best to reimplement the "for all installed packages, see if
they are out of date" logic, as pkg_chk is doing much more than pkg_rr
needs.

As a workaround, I modified pkg_rolling-replace to ignore lines from
pkg_chk that containg "missing".  This is hacky, but if you've been
unable to get pkg_rr to run, updating to 0.24.7 and using "-uvk" will
likely work better for you.   I am running it now on a netbsd-8 box that
previously had 2019Q1 and hence PYTHON_VERSION_DEFAULT of 27.

My tentative plan is:

  add a function to take a PKGNAME/PKGPATH, and determine any other
  variables to be set when building, like _PYTHON_VERSION (or something
  better that has that effect), extensible to other multiversion
  packages.

  add a switch to pkg_rr to iterate over the installed packages, and for
  each figure out if it needs updating given any multiversion settings.
  If so, set the mismatch variable on the package.

  Change the main loop to use the mismatch variable instead of looking
  for mismatches.  Perhaps drop the use of -u; if you don't want that,
  don't set the variables.  Perhaps have -u mean 'set the mismatch
  variables", so pkg_rr -u does what it used to.


I wonder why PYTHON_VERSION or similar isn't recorded as a variable in
the binary package.  Is that just because it never occured to people, or
is there a reason not to?  Which variable should be recorded?  It would
be nice if the recorded variable could be set to force the same version
of a multiversion package.