Refactoring to remove alwaysAllowCliCommand argument from evaluate requests

[omarArm]

This PR should implement #503

In this PR, I did the following:

1. Removed some guards in the evaluate request for better host debugging

[cwalther]

I am not familiar enough with the expression evaluation stuff to give a meaningful review, but I support removing the restriction from commands that are not expression evaluations (start with >).

[jreineckearm]

@omarArm , as discussed earlier today, please review if the global handle should be create right after a reset of frameHandles. At the moment it looks like it wouldn't be available while running for auxGdb, yet still working? Could be an indication that choosing and consistently handling -1 as global frameId is enough.

[omarArm]

@jreineckearm It works while running for auxGDB because the value of globalFrameHandle is stored at the very first stackTraceRequest and it remains stored. This means while running any undefined frameId falls back to the value of globalFrameHandle

[jonahgraham]

I support what you are doing here in principle - but I don't understand what sequences you are allowing that used to be not allowed. Can you add a test with the sequence of commands that come from VSCode that you are trying to change behaviour of please?

I believe it would be a good idea to create a frame handle for global expressions in which undefined frameIDs would fall back to.

This seems like a reasonable thing to do when the adapter has info that the front-end isn't able to provide. However, I don't understand why the default of using thread 1 is the reasonable thing to do in this case.

[omarArm]

@jonahgraham I am trying to allow CLI commands for host debugging. As the old pattern had the argument alwaysAllowCliCommand always set to false for host debugging. I removed the argument altogether.

I will try to add a test for it sure. I initially had the idea that the normal test routines provided in the evaluate request are enough.

As for the global frame handle, threadId = 1 and frameId = 0 are just place holders because the mi layer always sets up the command with --frame --thread. However, we are going to use floating frame-addr, so the threadID and frameID are going to be discarded by GDB anyway. For some reason though, gdb-mi did not accept having threadId = 0 while frame-addr = @. Therefore, I opted for the place holder.

Actually I will add a comment in the code explaining the whole pattern to avoid future confusion.

Edit: I removed the global handle from this PR. I figured the idea of supporting undefined frameIDs still need more investigation before getting into providing solutions

[jreineckearm]

Apologies for the back and forth here. I think we tried to do too much in one go and didn't think the thread ID part through. I agree with the proposal to move the undefined theads/frame ID behaviour to a separate PR. #503 should be kept open for the time being.

The change done here should deal with removing the artificial limitations we introduced earlier for the gdb type while getting up to speed with the code base. I am still testing that part (or better trying to set up a gdb session suitable for testing), hence no approval yet. That should help to validate eclipse-cdt-cloud/cdt-gdb-vscode#202

I appreciate that you will be a way for a couple of weeks soon, @omarArm . Hence, we either have to park the next steps on #503 . Or someone else takes over. Need to see what my own bandwidth allows until you are back....

[omarArm]

I found out that this won't properly work with gdb type. Hence, this PR needs more investigation. I am going to convert the PR into a draft instead until further notice.