Improve Viewport and Viewport::WalkInBounds

[lhecker]

This removes all of the 2D iteration machinery. Imagine the text buffer
as a Cell[w][h] grid. Clearly, this is identical to a Cell[w*h]
array, which shows that copying between overlapping ranges only needs
either forward or backward copying, and not left/right/top/down.

With WalkDir removed, WalkInBounds can be rewritten with basic
arithmetic which allows pos to be an exclusive end coordinate.

[lhecker]

Section 11.3.6.8 DECCRA seems okay in vttest:

Not sure if there's anything else I can do to test the DetermineWalkDirection function.

[zadjii-msft]

I'd be reluctant to merge this for 1.21 based solely on the fact that these are used everywhere and I'm guessing that bugs in the delta will be very subtle. But I'd be very happy to merge early in 1.22 when we've got more runway to validate.

(I'm also open to being overruled)

[lhecker]

@zadjii-msft Here's why the tests failed... I previously had this as:

bufferViewport.WalkInBounds(afterPos, dx);

but on closer inspection of the old code I noticed that the dx is meant inverse to an offset. I don't quite understand the old code to say why that is, but it does work now by simply using -dx.

I guess I'm being overly defensive over my PR here, but I do think it's fairly solid after all. 😅 (To be clear I don't mind merging it in 1.22 only.)

[j4james]

FWIW, I've run a number of my own rectangle and scrolling tests on this branch, and I couldn't see any regressions.

[carlos-zamora]

@lhecker Make sure you test this with Narrator. The bounding rects aren't updating for me.

[lhecker]

@carlos-zamora I believe this is a race condition in the UIA implementation. I found that it also reproduces in the stable builds (here: v1.20; repeatedly open cmd and hold any key immediately):

The new-ish Terminal::_assertLocked() catches this bug: The culprit is the constructor which doesn't lock the console when asking for the viewport and cursor position.