I rewrote the patch to better handle multi-line input. In rewriting the
patch I realized that there can be many different ways to handle up/down
key presses while the cursor is in the input region. Here is the
behavior of this patch:

For single line inputs:
* If the cursor is at the end of the line, then up/down navigates the
history.
* If the cursor is not at the end of the line, then up/down places the
cursor at the end, so that subsequent up/down navigates the history. 

For multi-line inputs:
* If the cursor is at the end of the input and the input is in the
history, then up/down navigates the history.
* If the cursor is at the end of the input and the input is NOT in the
history, then up will move the cursor up.
* If the cursor is at the first line of the input, then up will be ignored.
* If the cursor is on the last line of the input, then down will be ignored.

If the cursor leaves the input area, either by pressing left at the
start of the input area, or by clicking elsewhere in the text box, the
up/down keys behave as they do now.

If the cursor is outside the input area and a character key is pressed,
the cursor is placed and the end of the input, and the character is
placed there. 

Also, this patch fixes a subtle cursor placement bug when dealing with
multi-line inputs. When navigating from line 2 to line 1 of a
multi-line, the cursor can end up in the ">>>" prompt. This is fixed so
that the cursor stays in the input area.