Fixes for GUI toolkit to properly handle WM_DESTROY on Windows

This pull request needs a bit of explanation.  On modern Windows systems (7 and higher at the very least), shutdown is regularly blocked by the Open Watcom IDE.  After some investigation, the cause was found to be that the IDE does not properly respond to WM_DESTROY messages.  It does respond to WM_CLOSE properly, but a shutdown event will trigger WM_DESTROY without a WM_CLOSE (apparently).

The GUI toolkit appeared to have double-accounted for WM_DESTROY messages.  If the window was the root window, it would destroy the window's toolbar and execute the default window procedure, failing to ever execute the actual WM_DESTROY code.  WM_CLOSE would cause this condition to be skipped for whatever reason, however.

The odd double-accounting seems to be caused by the need to deallocate a possible toolbar.  There are remnants of code elsewhere that have been commented where the toolbar was properly destroyed.  Reactivating them obviously led to crashes, the original reason the toolbar freeing code was moved.

Freeing the toolbar was crashing because it would trigger a resize event.  Normally this behavior is fine because, when the toolbar is destroyed, we need the background window (OW is adding a static background to its child windows) to resize to refill the space.  However, if we're destroying the parent window, requesting a resize causes a crash while enumerating children, which have already been freed.  Now the window flags are checked on toolbar destruction to see if we're currently in the process of destroying the parent.  If so, the resize step is skipped, and the crash due to enumerating nonexistent children is avoided.

So that's the long explanation.  The IDE now properly closes on Windows NT when issued a WM_DESTROY event.