Again, fixing TextInput to handle UTF8 strings better.

When variable length coded UTF8 code points are written to a staticly sized
buffer, the length of the string, as code points, is also varying. Some
characters take up-to 6 bytes to represent.

Now if we are inserting multibyte UTF8 code point near the end of the
static buffer, it might not fit into the buffer, so we cancel the
insertion. There still can be characters that are representable with less
bytes after the insertion point. For the user of text input with this
behaviour looks like a bug.

Only solutions that I can think of are:
  1) Use dynamic buffer. Now the user never sees the 'bug' happening because
     there is always room for new code points.
  2) Use UTF32 encoding. As UTF32 is fixed length coded so any code point
     can be inserted at any place if there is still room for at least one.