The problem apparently was that the GraphiteWinLayout::DrawTextImpl()
function drew each glyph using a separate call to ExtTextOutW().  That
mishandled anti-aliased glyphs (alpha), somewhat in the way as
described in the nice long comment (thanks kendy!) in
WinLayout::DrawText().

The irony here is that in the case of Graphite fonts and OpenGL, it is
exactly from that code block in WinLayout::DrawText() that
GraphiteWinLayout::DrawTextImpl() gets called, and in that situation
it itself runs into the same or similar problem as the calling code
wants to avoid for the run as a whole. It draws each glyph separately,
and subsequent glyphs will overwrite the rightmost pixels of the
earlier one instead of blend properly. Or something like that.

As a solution, change the interface of DrawTextImpl() so that instead
of being called once to draw a run of text, it might draw just a part
of the run, and in that case expects to be called repeatedly to draw
the whole text.

The GraphiteWinLayout::DrawTextImpl() implementation does it like this
in the case of using OpenGL (as indicated by the presence of a
non-null pRectToErase, as added in
b7842c93 for tdf#95648). The end
result is that it draws one glyph at a time into the DC for the bitmap
allocated in the caller, WinLayout::DrawText(). The caller uses that
bitmap as a texture and blends it into the actual destination,
separately for each glyph.

For non-Graphite fonts, or when not using OpenGL, nothing should
change. No repeated DrawTextImpl calls are done to iterate over a run.

Change-Id: Ib7adc30665fc7804913fd2f8886c5b29d9ca42c4
(cherry picked from commit 61085083)