bug#48117: 28.0.50; Update of loaddefs.el during normal build is unreliable

[Eli Zaretskii <eliz@gnu.org>]

> From: Glenn Morris <rgm@gnu.org>
> Cc: 48117@debbugs.gnu.org
> Date: Fri, 30 Apr 2021 11:22:00 -0400
> 
> This issue has been present forever.

Yes, I know.  This isn't trivial, or else it would have been solved
long ago.

> 1) autoload generation is slow.

Based on my latest experience, I think this is somewhat exaggerated,
especially given that our builds became slower lately.

> 2) the dependencies of the loaddefs files are unknown to make,
> and are basically "all lisp files". (You can't even say "just those
> files with autoload statements", because removing a previously existing
> autoload statement changes the output.)
> 
> 3) Traditionally, re-making loaddefs files could make trivial changes
> to the output that weren't important (eg ordering of the "no
> autoloads" section, timestamping), but would still trigger re-dumping emacs.
> Which could then trigger regeneration of the autoloads, and
> re-dumping, etc.  This may be better nowadays, since there is no
> longer timestamp information in the loaddefs files (see autoload-timestamps).

What worries me the most is that when 'autoloads' is run (and it is,
from time to time), we still end up with outdated loaddefs.el.  I
think we could live with outdated loaddefs.el for short periods of
time, but it looks like running 'autoloads' only updates the part(s)
of the file for Lisp files that the build thinks to be responsible for
the update.  Or something like that, because how else to explain that
some parts remain outdated?