bug#9000: patch for higher-resolution time stamps

[Paul Eggert <eggert@cs.ucla.edu>]

Currently, Emacs supports time stamps to at most microsecond
resolution, and often to only 1-second resolution, even though most
modern systems have nanosecond-resolution time stamps for clock and
file time stamps.  This leads to some problems, for example:

 * "C-u M-x copy-file RET A RET B" discards the fractional part of A's
   time stamp when copying A to B (except for Windows, which I've been
   told uses special code to preserve the time stamp correctly).

 * The file-attributes function truncates file time stamps to
   one-second resolution, making it impossible for a dired written in
   Emacs to emulate the behavior of "ls --full-time".

 * (format-time-string "%s.%N") is supposed to output
   nanosecond-resolution time stamps, but on the Emacs trunk it always
   outputs a multiple of one microsecond, even when the system clock
   supports nanosecond resolution.

 * If some other process modifies a file during the same second that
   Emacs gets the file's time stamp, Emacs won't notice the conflict,
   as the visited-file-modtime function supports only 1-second
   resolution.  If Emacs used nanosecond-resolution time stamps, this
   race condition would be much less likely.

None of these problems are fatal, but they are annoyances that could
lead to real problems (e.g., when working with "make", which uses
high-resolution file time stamps).

I've proposed a patch for this:

http://lists.gnu.org/archive/html/emacs-devel/2011-07/msg00015.html
http://lists.gnu.org/archive/html/emacs-devel/2011-07/msg00016.html
http://lists.gnu.org/archive/html/emacs-devel/2011-07/msg00017.html
http://lists.gnu.org/archive/html/emacs-devel/2011-07/msg00018.html
http://lists.gnu.org/archive/html/emacs-devel/2011-07/msg00019.html
http://lists.gnu.org/archive/html/emacs-devel/2011-07/msg00020.html
http://lists.gnu.org/archive/html/emacs-devel/2011-07/msg00021.html

Stefan asked me in
<http://lists.gnu.org/archive/html/emacs-devel/2011-07/msg00069.html>
to make the patch more upward-compatible, by appending a new
picosecond count to the end of the time stamp list, rather than
changing the microsecond to a nanosecond count (which would likely
break more code).  I'll do that soon, but thought I'd first file a bug
report to make this whole issue easier to track.

In part I am also following up to Stefan's suggestion
<http://lists.gnu.org/archive/html/emacs-devel/2011-07/msg00217.html>
to have a bug report for this issue.