Fix body scroll issues when iOS keyboard pops up.

When, after clicking in the text, the iOS keyboard
pops up, the entire editor body is scrolled upwards
because the window is shrunk, even if there was
no way to scroll it before.
This means that the toolbar slides upwards and out
of the visible part of the viewport.

This is unacceptable, therefore this commit introduces
a fix:
* Listen for a scroll event, and upon catching it,
set the body's scrollTop back to 0. Add exactly the
scrolled amount worth of pixels to the canvas container's
padding-bottom, and scroll by exactly that additional
amount of pixels. As a result, when the keyboard opens,
after a slight flicker, the toolbar appears in the same
position as before, and the clicked area in the document
is inside the visible part of the viewport, unobscured by
the keyboard. This means that even if you scroll to the
very bottom of the document and click the last line of
text, it will not be obscured by the keyboard.
* Listen for a focusout event, which is triggered when
the keyboard is asked to hide (or by clicking outside).
If we do nothing, the toolbar will slide down into
the middle of the document and the additional padding
given to the canvas's container will remain. Therefore,
undo that.
Overlay the eventTrap outside and over the cursor.

This commit pulls the event trap outside the cursor,
and makes the IME track the cursor's position and
position the trap above the cursor.

This means that there is no need to manually
blur and focus the eventManager whenever an
operation is executed.
Do not set focus in a timeout on iOS.

When attempting click-to-move, in most desktop
browsers we need to get the new selection in a
simple 0-timeout, because the window selection
is not immediately updated when handling the
mouseup event. The focus to the event trap is
set after this is ready. Otherwise, clicking
within a selection will not do anything.

Unfortunately, in iOS Safari, it is impossible
to set focus within a timeout. Therefore, this
commit takes the least painful and simplest
thing route: check navigator.platform for
iPad, iPod, and iPhone (the hope is that this
will be reliable because of Apple's consistency),
and in that case avoid computing the selection
and focus assignment within a timeout.