four-part version numbers cause autopoint to fail

[Karl Berry]

autopoint --version reports four-part version numbers in such releases,
as in (having unpacked and configure && make the original
gettext-0.19.8.1.tar.xz):

$ ./gettext-tools/misc/autopoint --version
./gettext-tools/misc/autopoint (GNU gettext-tools) 0.19.8.1

However, autopoint does not actually support such four-part versions:

$ cat configure.ac
AC_INIT([foo], [1.0])
AC_PROG_CC
# Both required by autopoint.  Newer gettext (0.20+) requires external.
AM_GNU_GETTEXT([external])
AM_GNU_GETTEXT_VERSION([0.19.8.1])
$ autopoint -f
autopoint: *** The AM_GNU_GETTEXT_VERSION declaration in your configure.ac
               file requires the infrastructure from gettext-0.19.8.1 but this 
version
               is older. Please upgrade to gettext-0.19.8.1 or newer.
$

(It's understandable how that message came about, but since the current
infrastructure is in fact 0.19.8.1, it doesn't actually make
sense. Aside: it's also unnecessary/undesirable (IMHO) to have output
lines >79 chars here.)

This is apparently because the case statement in autopoint[.in] does not
list four-part releases:
  ...
  0.18 | 0.18.1 | 0.18.2 | 0.18.3 | \
  0.19 | 0.19.1 | 0.19.2 | 0.19.3 | 0.19.4 | 0.19.5 | 0.19.6 | 0.19.7 | 0.19.8 
| \
  0.20 | 0.20.2 | \
  ...


The end result is that automake's gettext tests are disabled with
four-part gettext versions, because they use the version number from
autopoint --version to create the configure.ac for testing.
reasonable. I guess I will change automake to remove a fourth part,
since it apparently works if configure.ac uses 0.19.8.

0.19.8.1 is, unfortunately, the version distributed with Alma Linux 8
and, presumably, all RHEL 8.

In general, it seems bad to have release numbers that do not support
themselves. I see no four-part release has been made in some years, so
maybe it is already policy to avoid them. But just in case, I thought
I'd mention this discrepancy. --happy hacking, karl.