Handling Shift+Enter Correctly

Testing continues and no new problems have be found so far.  However, an unrelated problem was discovered with the Shift+Enter key sequence.  When there was no selection, a Shift+Enter behaved liked a regular Enter, either moving to the next line or entering a new line if the cursor was at the end of the line.  But if there was a selection, a new line character was inserted in the middle of the line.  This was evidenced because no line number was displayed including in the program view, which is the same as for a long line.

Normally, the plain text edit widget allows the insertion of a new line with Shift+Enter (like word processors).   The reimplemented edit box key press event handler partially changed this behavior, but the old behavior remained when there was a selection.

I decided to make a Shift+Enter behave as extending the selection (or starting a selection if none is present) to the beginning of the next line.  This is the same as when holding the Shift with other movement keys (arrows, Home, End, etc.).  There is no reason to allow new lines to be inserted in the middle of program lines.

This was corrected by incepting the Shift+Enter key sequence first.  The same moveCursor()  function is called with the same NextBlock move operation, but instead of using the default MoveAnchor move mode, the KeepAnchor move mode was added, which extends (or starts) a selection.

[commit 32149da677]