I spent some time thinking on how to get this new revert command
integrated with the rest of revert-buffer functions, and I came up with
the attached patch.

Since the difference between revert-buffer and
revert-buffer-with-fine-grain lies at the insert-file-contents level, I
wrote an alternative to
revert-buffer-insert-file-contents--default-function, that uses
replace-buffer-contents, as Eli suggested.  I named it
revert-buffer-insert-file-contents-delicately.

Then, revert-buffer-with-fine-grain only needs to bind
revert-buffer-insert-file-contents-function to
revert-buffer-insert-file-contents-delicately to get the job done.

There are some more things that revert-buffer-with-fine-grain needs to
do:
1) Manipulate the current-prefix-arg, just like revert-buffer does.
2) Since replace-buffer-contents can fail to replace conservatively,
return that information could be useful.  But revert-buffer--default
always returns t after reverting, so I used a closure that then gets
called by revert-buffer-with-fine-grain.

To control how much time replace-buffer-contents spends trying to be
non-destructive, I introduced a new variable to pass as the MAX-SECS
argument.  2.0 secs looks like a good value, according to the previous
benchmark I posted, and the new one I post here.  I think it should be
an acceptable delay.

As I said above, I timed the command, and to compare I timed
revert-buffer too.  IMO, the results look good.  Some files fail and
take a lot of time, yes, but I think it's unlikely that a user will revert
so many changes.  And for those, at least the variable
revert-buffer-with-fine-grain-max-seconds helps to terminate the
execution earlier.

I also went ahead and wrote a test for revert-buffer-with-fine-grain,
because I figure it would be required, as well as the benchmarking.
As I was there, I wrote a similar test for revert-buffer.

Corrections and comments are welcome.  Better names too.

Best regards,
Mauro.