Certain characters are considered by GetTextExtentExPointA/W/I to have no width, even if they have a non-zero width and a shape in the font. This MR attempts to bring Wine's implementation of these functions closer to native behavior.
One remaining difference is caused by GetGlyphIndicesA/W returning 0 instead of 0xffff for some characters, for some reason. This also affects the handling by GetTextExtentExPointA/W/I of affected characters. I have compared this with both Uniscribe and DWrite behavior and neither of them match this behavior, so it seems to be a peculiarity of these older functions.
Remaining differences are probably caused by differences in the fallback fonts used when a character is missing from the selected font. Notably, on my system there doesn't seem to be a fallback font for `\t`/`\n`/`\r` that marks those characters as zero-width, and since applications are likely to depend on the metrics of those characters (I know of at least one), I have opted to explicitly make them zero-width in this MR, even though that is technically not what Windows does.
-- v5: win32u: Handle glyphs that are marked by the font as zero-width in GetTextExtentExPoint[AWI]. win32u: Use maximum of (A, A+C, A+C+B) width for character fit test in GetTextExtentExPoint[AWI]. gdi32/tests: Add test for width of carriage return and line feed.