TranscriptScreen: increase mTotalRows when resizing if needed

Currently, when you attempt to increase the number of screen rows in a
TranscriptScreen beyond the value of mTotalRows supplied when the
TranscriptScreen was initially created, the backing store allocated in
init() will not be large enough to hold the contents of the screen.
This results in strange behavior, such as duplicate lines or lines
overwriting each other in full-screen applications.

Fix this by bumping mTotalRows as needed when resizing.
TerminalEmulator: fix screen resizing when alternate buffer is in use

A full resize of the screen while the alternate buffer is current (e.g.
if GNU screen or another fullscreen terminal application is running)
can currently crash with the following stack trace:

java.lang.IllegalArgumentException
	at jackpal.androidterm.emulatorview.UnicodeTranscript.setChar(UnicodeTranscript.java:727)
	at jackpal.androidterm.emulatorview.UnicodeTranscript.setChar(UnicodeTranscript.java:714)
	at jackpal.androidterm.emulatorview.TranscriptScreen.set(TranscriptScreen.java:99)
	at jackpal.androidterm.emulatorview.TerminalEmulator.updateSize(TerminalEmulator.java:464)
	[...]

This happens because TerminalEmulator is trying to mark the position of
the cursor in the alternate buffer, but the alternate buffer was already
resized.  There's no guarantee that the current location of the cursor
is still a valid position on the resized screen, and if it isn't, the
exception above is thrown.

Even when the terminal doesn't crash, resizing the screen causes the
screen to blank briefly until the application redraws the screen, since
the contents of the alternate buffer are discarded during the resize.

To fix this, we note that when resizing the screen, we don't actually
need to care whether the main or alternate buffer is current -- we just
want to resize the current buffer (whichever one that is).  Therefore,
instead of treating the main and alternate buffers differently during
resizing, we just work with the active buffer.

In principle, we could defer the resizing of the inactive buffer until
it becomes current, but this introduces the possibility of latency at
some undetermined future time (when the buffers are swapped).  It's
probably better to do the work during the resize event itself, when the
user is more willing to tolerate a pause and there's usually an
animation to help disguise it.  (The alternate buffer has no scrollback,
so even a full resize will be relatively quick; therefore, the only case
where this could become noticeable is when the alternate buffer is
current, but the main buffer has a very long scrollback.)  We therefore
resize the inactive buffer immediately, taking some care to avoid
problems with cursor positioning (in particular, we can't trim blank
lines, because without the cursor position marking, we can't be sure
whether they're significant or not).
Merge branch 'steven676-for-upstream'