bug#1849: Windows 7 Taskbar Support

["Michael Kleehammer" <michael@kleehammer.com>]

To work well with the upcoming Windows 7, the Windows version of emacs will need
to start from emacs.exe without allocating the extra console window.  This means
it will need to be linked as a GUI program instead of a console program.

In previous versions of Windows, the Quick Launch shortcuts were small icons
that launched programs.  The programs were then allocated a new button in the
taskbar.  Windows 7 consolidates these: the shortcuts are also the taskbar
buttons.  Similar to the Mac OS/X dock, when a program that has a shortcut is
run, it is not allocated a new taskbar button - instead, the shortcut is
highlighed differently.

This obviously assumes that the program consists of a single main executable
that the shortcut launches.  Unfortunately, emacs on Windows is a console
program which creates an unwanted "DOS" window.  To run as a GUI, a special GUI
launcher named runemacs.exe is used which hides the console window.

To launch emacs, the user will need to pin runemacs.exe.  When launched, it
starts emacs.exe and immediately exits, causing two problems: (1) the shortcut
does not stay highlighted to indicate the program is running and (2) a 2nd
taskbar button is created for emacs.exe.

If a user pins emacs.exe, it will always create an extra console window, so that
is not an option either.

The proper "fix" is to compile the Windows version of emacs.exe as a GUI
program, not a console program, which is a very simple change.  It would
eliminate the ability to run emacs on Windows in a console window, however.

First, this is probably acceptable to 99% of users.  In fact, I don't know of
anyone that runs emacs on Windows in a console, but I'm sure someone does.
(Remember, there is no SSH or the like; we're talking Windows here ;)

If needed, the makefile could be updated to build either or both.

I think it would be simple to compile the program as a GUI program but have the
-nw flag allocate a console when needed.