Fix VtEngine hang when resizing while scrolling

[lhecker]

This fixes a bug reported internally that occurs when resizing the
terminal while also scolling the contents. The easiest way to reproduce
it is to resize the terminal to 0 rows, but it's much more prominent
in a debug build where everything goes out of sync almost immediately.

The underlying issue is that VtEngine::_wrappedRow may contain an
offset that is outside of the viewport bounds, because reflowing and
scrolling aren't properly synchronized. The previous bitmap code
would then throw an exception for such invalid coordinates and cause
the internal VtEngine state to be broken. Once _wrappedRow got
to a negative value at least once, it would stay that way unless you're
scrolling up. If the contents are actively scrolling it would quickly
reach a negative value from which it can never recover. At that point
OpenConsole would enter a tight exception-throw-catch-retry loop
and Windows Terminal seemingly cease to show any content.

Validation Steps Performed

• Resize WT to the minimal window size repeatedly
• Doesn't hang ✅

[lhecker]

I chose to change til::bitmap instead of VtEngine, because I think til::bitmap shouldn't throw for out of bounds coordinates.

Furthermore, fixing the reflow/scroll aspect of VtEngine might be a losing battle, because reading through the _wrappedRow implementation gave me the impression that it's not doing the right thing anyways. XtermEngine::ScrollFrame() in particular sets _wrappedRow to nullopt temporarily and then restores its initial value which is... weird? It's definitely a "spooky action from a distance" anti-pattern. 😅 ...and not very exception safe either. If we were to fix VtEngine I would instead opt to fix it fundamentally. I'm sure that whetever delay-wrap logic we got, we can solve some other way and more robustly too, for instance with out-of-bounds coordinates, etc. 🙂