Move window resize timeouts into the GTK frontend.

In the changes around commit 420fe75552, I made the terminal
suspend output processing while it waited for a term_size() callback
in response to a resize request. Because on X11 there are unusual
circumstances in which you never receive that callback, I also added a
last-ditch 5-second timeout, so that eventually we'll resume terminal
output processing regardless.

But the timeout lives in terminal.c, in the cross-platform code. This
is pointless on Windows (where resize processing is synchronous, so we
always finish it before the timer code next gets called anyway), but I
decided it was easier to keep the whole mechanism in terminal.c in the
absence of a good reason not to.

Now I've found that reason. We _also_ generate window resizes locally
to the GTK front end, in response to the key combinations that change
the font size, and _those_ still have an asynchrony problem.

So, to begin with, I'm refactoring the request_resize system so that
now there's an explicit callback from the frontend to the terminal to
say 'Your resize request has now been processed, whether or not you've
received a term_size() call'. On Windows, this simplifies matters
greatly because we always know exactly when to call that, and don't
have to keep a 'have we called term_size() already?' flag. On GTK, the
timing complexity previously in terminal.c has moved into window.c.

No functional change (I hope). The payoff will be in the next commit.

terminal/terminal.h

@@ -427,24 +427,6 @@ struct terminal_tag {
         WIN_RESIZE_NO, WIN_RESIZE_NEED_SEND, WIN_RESIZE_AWAIT_REPLY
     } win_resize_pending;
     int win_resize_pending_w, win_resize_pending_h;
-
-    /*
-     * Not every frontend / TermWin implementation can be relied on
-     * 100% to reply to a resize request in a timely manner. (In X11
-     * it's all asynchronous and goes via the window manager, and if
-     * your window manager is seriously unwell, you'd rather not have
-     * terminal windows start becoming unusable as a knock-on effect,
-     * since those are just the thing you might need to use for
-     * emergency WM maintenance!) So when we enter AWAIT_REPLY status,
-     * we also set a 5-second timer, after which we'll regretfully
-     * conclude that a resize is probably not going to happen after
-     * all.
-     *
-     * However, in non-emergency cases, the plan is that this
-     * shouldn't be needed, for one reason or another.
-     */
-    long win_resize_timeout;
-    #define WIN_RESIZE_TIMEOUT (TICKSPERSEC*5)
 };
 
 static inline bool in_utf(Terminal *term)