bug#19868: 25.0.50; Compilation eats buffers

[Richard Copley <rcopley@gmail.com>]

On Windows, with MinGW gcc.exe installed and on the path, save a file
"c:\temp\bug.c" containing these two lines:

#include <windows.h>
int main () { Sleep (5000); }

Compile with "M-x compile RET", supplying this compile-command:
gcc -mwindows -o bug.exe bug.c && bug.exe

Within 5 seconds, execute "M-x compile" again and answer "yes" to kill
the existing process. The process doesn't respond to the signal,
and Emacs hangs inside the call to `delete-process' in
`compilation-start'.

When the process does eventually die and the `delete-process' call
returns, the current buffer has changed from *compilation* to the buffer
from which the compilation was launched (which will often be a source
code buffer).

`compilation-start' then proceeds to erase the buffer and discard its
undo history. This is potentially very bad news for the user's source
code.

I'm not sure where the buffer gets changed (presumably in a sentinel,
but `compilation-sentinel' looks OK to me). Wrapping the
`delete-process' call inside a `save-excursion' fixes (or hides?) the
problem.


In GNU Emacs 25.0.50.1 (x86_64-w64-mingw32)
 of 2015-02-09 on MACHINE
Repository revision: 21d1f8b85eec8fc1f87bb30398e449f6b20b6ecc
Windowing system distributor `Microsoft Corp.', version 6.3.9600
Configured using:
 `configure --prefix /c/emacs/emacs-20150209-192633
 --disable-dependency-tracking
 --enable-locallisppath=%emacs_dir%/../site-lisp --with-wide-int
 --build=x86_64-w64-mingw32 'CPPFLAGS=-I G:/usr/include -I
 C:/GnuWin32/include' 'LDFLAGS=-L G:/usr/lib -L C:/GnuWin32/lib''

Configured features:
XPM JPEG TIFF GIF PNG SOUND NOTIFY ACL GNUTLS LIBXML2 ZLIB