bug#20943: 25.0.50; Dired buffers are not always auto-reverterd

[Drew Adams]

> This is a feature of dired. It doesn't want to regenerate the whole
> dired buffer; instead it adds the new entry at the position the
> cursor is pointing to. This is because reverting the dired buffer
> could be expensive. Think about a remote directory, think about many
> inserted subdirectories.

Dunno whether performance was the only reason for doing this, but
another benefit I see to the current behavior is that, because the
change is shown next to point, *you see it*, even if `g' reordering
might place it far way or even off-screen.  It is important that
users have feedback about changs.  And when the changed/new file
is somehow derived from the file at point (e.g., it is a copy),
seeing the two right next to each other means you can immediately
compare the names etc. 

This keep-it-right-here-for-now behavior is quite important, (to me
at least). When I copy a file to the same directory, for instance,
and give the copy a name with a prefix (e.g. 2015-07-04) that might
make it sort far away, I can nevertheless see it right there.

This is about the same reason that we highlight new files (e.g.,
copies) specially, so you notice them easily.

This gives users control over when to re-sort (using, e.g., `g').
We should not assume that re-sorting automatically is what a user
wants.

If we were to change this, I would very much like the changed
behavior to be only an option, and not the default behavior.