REPL -exec can cause MIEngine to lose Thread/Frame context

When I do a -exec in the REPL window, I can change gdb's concept of current thread/frame.

Say, the last command executed by MIEngine could have been on thread 1, frame 7 which is the current context in the 'Call Stack' window. MIEngine sets gdb to this context but also saves this context. Then in the REPL window, I do

-exec -data-list-register-values -thread 2 -frame 3

I follow that by a simple eval (not a -exec). Normally, this is executed in the current context in the 'Call Stack' window which say is still on 'thread 1, frame 7` and cause MIEngine, gdb and VSCode to get out of sync.

$pc

Since neither thread/frame changed according to MIEngine's view of the world, it does not ask gdb to select the appropriate thread/frame. This causes future commands/requests/evaluates intended for Thread 1, Frame 7 to occur on thread 2, frame 3 and gives wrong results....until the user clicks on some other frame in the 'Call Stack' window.

There is also a second problem with -exec. Let's say, in the call stack window, I have frames 0-2 (0 being where it was stopped) and (2 being the bottom of the stack -- usually main). Click on frame 0, and execute the command -exec print $pc. Repeat for frames 1 and 2. You will see that the $pc variable is different in each frame. Now go back to frame 0 and do a -exec print $pc You will not see the right value. Regardless of which frame you select, you will only see the value from frame 2. You can even switch threads and now it gets really confusing.

Since things are cached in VSCode (it appears), MIEngine never gets a scopes or variables request and thus both MIEngine and gdb are still thinking the current frame is 2, since that was the last time any real interaction occurred between VSCode and MIEngine. All -execs happen in that context regardless of what the context is in the 'Call Stack' window..until the user clicks on a frame not previously visited.

The REPL evaluate request call does supply a proper frameId but in the case of -exec it is ignored in MIEngine (not passed down to gdb). I can fix it, we must do a context set/save, before the -exec and restore the context after. I am in the middle of adding 'Registers` support to MIEngine though. Should I do a separate PR?

Start with the MIEngine REPL evaluate request path, focusing on how the supplied frameId is handled for -exec commands. Compare the current context saved by MIEngine with gdb's selected thread and frame, then verify that context is set before -exec and restored afterward. Done means REPL commands use the requested thread and frame without leaving later evaluations out of sync.