Attempt fixing repetitive chars in Japanese IME

[lhecker]

Users report in issue #14349 that the Japanese IME may print repetitive
characters since v1.15. The two potential offenders are:

• 2c922e1
• ed800dc

I don't think either of the two commits themselves is "buggy", but
rather that they make bugs in TSF obvious. This is because backspacing
causes TermControl::_CharacterHandler to be called, which will then
call TSFInputControl().ClearBuffer(), which should instruct TSF
to flush its entire buffer and reset its state.
That doesn't seem to be happening though.

I think what's happening here is that TSF is either:

• ignoring this request
• getting into a bad state
• running into race conditions due to running out-of-process

2c922e1 could have triggered the
regression because it drops clamping the signed range values from TSF.
I believe at the time I didn't consider it possible that TSF would
actually pass either negative indices or a range where
StartCaretPosition is greater than EndCaretPosition.

ed800dc could have triggered the
regression because it changed this (simplified):

_activeTextStart = min(_activeTextStart, range.StartCaretPosition);

into this:

_activeTextStart = min(_activeTextStart, _inputBuffer.size());

I think the latter is technically more correct, but if TSF is in a bad
state where it didn't properly reset, then this may be off.
(When the buffer contains "foo" and the _activeTextStart is 3 (= end),
then we shouldn't move the start to 0 just because TSF replaced the
entire string with "foobar", since the active part is just "bar".)

Closes #14349

Validation Steps Performed

• Japanese IME (Full-Width Katakana)
  Typing "saitama" produces "サイタマ" ✅
• Korean IME
  Typing "gksrmf" produces "한글" ✅
• Vietnamese IME
  Typing "xin chaof" produces "xin chào" ✅
• Emoji Picker (Win+.)
  ✅

[lhecker]

replace() returns a reference to *this, so assigning it to itself is not necessary.
(https://en.cppreference.com/w/cpp/string/basic_string/replace)

[lhecker]

FYI the ::base::ClampMin, etc., code in this class prior to 2c922e1 was not entirely correct either. For instance, it would pass range.StartCaretPosition to replace() directly.

Code like this:

const auto textEnd = ::base::ClampMin<size_t>(range.EndCaretPosition, _inputBuffer.length());
const auto length = ::base::ClampSub<size_t>(textEnd, range.StartCaretPosition);

is also not correct, since the T in ::base::ClampSub<T> acts just like the T in std::min<T>: It casts all parameters to <T> and then clamps the final value. That is, if you do ClampSub<size_t>(123, -1) it is the same as ClampSub(size_t(123), size_t(-1)) which is 18446744073709551615. In other words, a negative StartCaretPosition will result in length == SIZE_T_MAX (substr() doesn't really care, but... eh).

[lhecker]

This reverts part of ed800dc. It still seems to work.

[lhecker]

There's one more part that worries me about 2c922e1:
2c922e1#diff-1385b1ccad3b8d0ca82e24b8eb7ec11431204e3db23168e9ac620aa2476eb48fL124-R106

It works on my PC™️, but I'm worried that TSF has overflow bugs. I did this change, because back then I was already worried that TSF may go out of sync with our state. My hope was that this would reset TSF's internal text state, no matter what TSF thinks how much text we got.