Modernize CommandHistory and switch to int32

[lhecker]

This commit slightly modernizes CommandHistory by leaning more heavily
on the STL container functionalities. For one, it uses for-range
iterations to loop through _commands instead of using GetNth
on every iteration. Another major improvement however is that
the code previously copied entire CommandHistory instances out of
the linked list s_historyLists, then removed the slot and copied
(not moved!) that instance into the front again. Now it uses the
splice function from std::list to do it in O(1) and virtually
cost-free.

Another major improvement (and the one I'm personally interested in)
is the switch from SHORT to int32_t. This will greatly simplify
the implementation of the future COOKED_READ_DATA class, as the
larger integer type will remove worries about over/underflow.
For instance, we can then just blindly increment/decrement the history
position and then only later clamp it to the expected range.

Validation Steps Performed

• Existing history tests ✅
• History cycling with F8 ✅
• Navigating history with F7 ✅

[DHowett]

Ugh we have Get and Retrieve. Can we rename Retrieve to Copy? They're both synonyms otherwise, and I hate methods whose names are synonyms but behaviors are totally unrelated.

ALSO THIS UPDATES STATE WHERE GET DOESN'T.
AGH.

[lhecker]

If you don't mind, I'd rather not make such a change right now. It would make the diff quite a bit larger, which might not be a good timing, given that I'll very soon rewrite every other caller of these functions.

[KalleOlaviNiemitalo]

Windows Driver Frameworks likewise have Get and Retrieve; see https://learn.microsoft.com/windows-hardware/drivers/wdf/kernel-mode-driver-framework-architecture#object-properties

[DHowett]

Argh, I'll accept it!

[DHowett]

We lost the increment/move to next command version (491-486 Left). When did it happen? Why is it OK to remove?

[lhecker]

I originally didn't intend to refactor this function, but it really puzzled me what it does. Hence the rewrite - it's now much more straightforward IMO.

I only understood it when I approached the function from a "first principles" kind of viewpoint, asking myself what a remove function would have to do:

• Ensure that the given index is in bounds
• Remove the given index
• Since all items after the given index have shifted one slot to the left, any index referring to those items also needs to shift one to the left

That last point is what your question is about: If the LastDisplayed value is after the given index, the item it was referring to has shifted to the left in the vector, and so LastDisplayed must be decremented.

The previous code was only that complex because the history used to be a ring buffer and there used to be not 1 but 3 indices that had to be shifted around. And it was possible that the items would shift to the right (due to it being a ring buffer) and so LastDisplayed had to be incremented.
Due to the switch to a std::vector none of that is necessary anymore.

[DHowett]

AAAH FECK IT WAS A RING BUFFER

[DHowett]

Open Q about the increment codepath

[lhecker]

And this one got git rebase --onto origin/main dd231a397cbfdd54e7170eb0a60c3ebbef39f32e