window.c

RIP is currently the only thing that can change the number of lines
in the terminal while connected.  This can actually result in there
being more lines on the screen than the last set video mode supports.

There's a "feature" in SyncTERM text modes (curses, ANSI, and Win32
Console) where if the screen mode is "current", it uses the number
of lines in the terminal, but if it's anything else, it forces the
number of lines to the lines in the mode.

This works great until RIP increases the number of lines beyond the
number in the mode... when this happened, RIP would draw the status
bar at the incorrect location on the screen.

This change no longer sets the max rows in the terminal if the
backend can set individual pixels (required for RIP).  Further, to
avoid a delay before redrawing the status bar after RIP changes the
number of rows, the reinit_screen() function now sets a global to
indicate it was called, and the status bar will always redraw when
it's enabled and the flag is true.

This *may* be related to bug 140, but may not be.