Fix GTK puzzle resizing, *again*.

Fix GTK puzzle resizing, *again*.

Jonas Kölker points out that commit a800ff16b (which fixed a bug in
the previous attempt) left in another bug: if the puzzle size was
changed while the window was maximised, the system would fail to
recompute the tile size and would redraw completely wrongly.

So it's not optional after all to run midend_size(), even if the
drawing area size hasn't changed. I've reverted that code to be
unconditional, and now only the refresh of the Cairo-side backing
store system is conditionalised - and that's conditionalised on
changes to either the size of the actual window _or_ the size of the
contained pixmap. (The latter should defend against redraw failure in
the case where the puzzle aspect ratio changes, so that neither the
window size nor the tile size changes but a recentre is still needed.)

I _think_ this now fixes all the cases of resizing: this time I've
tested making an unmaximised puzzle window bigger or smaller, and
within a maximised window, forcing the puzzle to scale up, scale down,
or change its aspect ratio without changing its tile size. All work,
on GTK2 and GTK3, and yet we still don't get the visible flicker on
status line updates that was the reason I started fiddling with this
code in the first place.

(We _do_ still call configure_area on every update of the status line,
at least under GTK3; that's going to cause a forced full redraw on
every timer tick in Mines, which is wasteful of CPU, so it would still
be nice to find a better way of identifying the cases in which no
resizing at all was necessary and we could avoid renewing the game
drawstate. But the current code at least doesn't have any display
_errors_ that I know of, which is an improvement on its previous
state.)