The horizontal scrollbar works in WideSpaceWidth units (the width of 'x'),
but its extent was derived from GetVisualColumnFast, which counts characters
and assumes every one of them is exactly one column wide.

Any glyph wider than 'x' - CJK, emoji, glyphs coming from a fallback font, or
any proportional font - therefore makes the scroll range shorter than the line
actually painted. Depending on how far off it is, either the scrollbar is not
shown at all, or its thumb cannot be dragged to the end of the line. Setting
HScrollBar.Value from code (caret movement, selection drag) uses the accurate
GetVisualColumn and can reach Maximum, so those paths scroll further right than
the thumb allows - which is how the mismatch becomes visible to the user.

Replace the character count with GetVisualWidthColumns, which measures the
glyphs using the existing per-character width cache and mirrors the tab
handling of PaintLinePart. The cached line widths now depend on the font, so
they are invalidated on OptionsChanged.

Refs: gitextensions#63

A Graphics from Control.CreateGraphics() wraps a DC borrowed from the system
cache and is bound to the control's current window handle. Keeping one for the
lifetime of the control leaves a stale HDC behind once that handle goes away, so
the next layout pass throws "Parameter is not valid" out of
TextRenderer.MeasureText before it measures anything.

Scope it to the layout pass instead, which is the pattern every other
CreateGraphics() call in this library already uses. The ??= is kept, so a pass
which only reads cached line widths still creates no device context at all.

Refs: gitextensions#64
Co-authored-by: Bhanu Santin <bsantin@hemlock.com>
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>