Allowing undefined frames for evaluate requests and variables request

[omarArm]

In the method handling evaluate request, there exist a guard to discard requests without frameIDs that come with a context other than repl. 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 would entail the following:

1. Creating a frame handle for global expressions at the beginning of every stackTrace request. StackTrace requests are where frame handles are created. They are later all reset when stopped event and continued event are fired.

2. Remove the guard for undefined frameIDs from evaluate requests and assign undefined frames to the frame handle specified for global expressions. Current behaviour is that undefined frameIDs would get assigned with frame handle -1, which doesn't exist.

[jreineckearm]

This needs change in the adapter itself. I'll see if I can transfer the issue there.

I support this change, the global context is something that exists in GDB, as well as in the DAP specification. And it enables more operations while the target is running (those that strictly speaking need no connection to a stable stackframe).

I don't know all of the history of the varObj cache and the frameId strategy, but looking at some of the stale PRs, this was a topic before.

Please make sure to include active committers who are around for a little longer than me (like @jonahgraham and @asimgunes ) in the review.