automake: again revise file mtime resolution support.

automake: again revise file mtime resolution support.

This patch is from https://bugs.gnu.org/67670.

In order for the Automake testsuite to be able to use sub-second
delays to control whether certain files are considered newer
than others, five(!) separate pieces of software all need to
cooperate: automake itself, autoconf's internal `autom4te'
utility, the Perl interpreter and its libraries, the sleep(1)
shell utility, and finally the filesystem hosting the build
directory. The existing tests for this are a combination of
inadequate and incorrect. This patch, in conjunction with a
patch just committed to Autoconf trunk,
https://git.savannah.gnu.org/cgit/autoconf.git/commit/?id=39d96e6fff7ceae63b823872602caf4d255a38c8

should make everything much more robust, as follows:

- _AM_FILESYSTEM_TIMESTAMP_RESOLUTION is completely rewritten.
 It no longer looks for autom4te at all, because this macro is
 invoked unconditionally from AM_INIT, so *every* project that
 uses Automake would get this test that's only relevant to
 Automake's own testsuite. Also, it tries sleeping for as little
 as one millisecond (smaller delays consistently get rounded up
 to 1ms on my computer and I expect that's universal), it should
 accurately detect FAT's two-second resolution now, and it should
 not be tripped up anymore by running at precisely the moment
 that will make a 0.1s sleep cross a 1s boundary (this may sound
 unlikely but it used to cause a couple of test failures *every
 time* I ran the automake testsuite on a network filesystem that
 only supported 1s resolution).

- In support of the above, the test for working ls -t moved from
 AM_SANITY_CHECK to _AM_FILESYSTEM_TIMESTAMP_RESOLUTION. This
 allowed me to simplify the test for $srcdir/configure being
 older than a freshly created file.

- If automake is capable of reading high-resolution file
 modification timestamps from the operating system, it prints
 `Features: subsecond-mtime' as the second line of --version
 output. (We can't just assume this works for sufficiently new
 automake, because it depends on whether the Perl interpreter
 provides this capability, and that's not a simple question of
 which version of Perl you have, either.)

- The Autoconf patch mentioned above adds the same annotation to the
 output of autom4te --version.

- Finally, t/ax/test-defs.in looks for the
 `Features: subsecond-mtime' string from both automake and
 autom4te and resets the sleep time to one second if it's not
 there. There might be a better place to put this, somewhere
 it'll execute every time the *overall testsuite* is invoked
 rather than once for each test, but I couldn't find one.

Tested on x86-64-linux with development automake and development
autoconf.

Previous discussion:
- https://lists.gnu.org/archive/html/automake/2023-03/msg00000.html
- https://lists.gnu.org/archive/html/automake/2023-04/msg00002.html
- https://lists.gnu.org/archive/html/automake/2023-12/msg00005.html
- https://debbugs.gnu.org/cgi/bugreport.cgi?bug=64756

* m4/sanity.m4 (_AM_FILESYSTEM_TIMESTAMP_RESOLUTION): Rewrite for
greater reliability.  Don't probe autom4te at all here.
Check for working ls -t here.
(AM_SANITY_CHECK): Do not cache the result.
Do not check for working `ls -t' here.
Disentangle control flow in the loop probing the relative ages of
  build and source directory.

* lib/Automake/FileUtils.pm: Sync from autoconf.
* bin/automake.in (version): Include `Features: subsecond-mtime'
  in the output if $Automake::FileUtils::subsecond_mtime is true.
* configure.ac: Rename the substitution variable MODIFICATION_DELAY
  to MTIME_RESOLUTION.
* t/ax/test-defs.in: Require both $AUTOMAKE and $AUTOM4TE to report
  support for high-resolution timestamps before setting $sleep to
  delay for less than one second.
* NEWS: Update info.