Setting cursor position has too many routes

[miniksa]

Based on #2731, repeated here:

When it came to actually setting the cursor position, I found there were a number of options to choose from, with quite different behaviours. Some operations use a variation of SetConsoleCursorPosition, some use AdjustCursorPosition, and some call the SCREEN_INFORMATION::SetCursorPosition method directly, or even just Cursor::SetPosition. It wasn't always clear to why a particular method was chosen.

This certainly needs a follow up work item. I'm reviewing some of the code in each of these to try to come up with reasoning why you should use one over the other... and I'm realizing that this is probably the source of our "the cursor is blinking weirdly or is on when it shouldn't be while text is outputting" problems.

As far as I can tell, you've chosen the correct one with SCREEN_INFORMATION::SetCursorPosition because that one is responsible for updating the delay status on the cursor so it stays off or on instead of blinking wildly as it is moving rapidly around the screen when things are happening. The cursor is supposed to temporarily suspend blinking when there is activity (by the delay).

I am certain the inconsistency in application of which cursor-setting-function is being used is responsible for graphical glitches.

This work item represents auditing the cursor position setting methods to reconcile them into a (hopefully) more unified entry point. It probably also represents analyzing the assorted delay booleans that temporarily suspend cursor drawing to reconcile those as well. (Cursor::_fDelay and Cursor::_fIsVisible and Cursor::_fBlinkingAllowed and Cursor::fIsOn. and Cursor::f_DeferCursorRedraw.)

[miniksa]

Marking Help-Wanted because anyone is welcome to attempt to take on this task, but note that it probably has a larger scope than many other Help-Wanted tasks.