We can't let GetStackFrameCount get interrupted or it will give the wrong answer. Plus, it's useful in some places to have a way to force the full stack to be created even in the face of interruption. Moreover, most of the time when you're just getting frames, you don't need to know the number of frames in the stack to start with. You just keep calling Thread::GetStackFrameAtIndex(index++) and when you get a null StackFrameSP back, you're done. That's also more amenable to interruption if you are doing some work frame by frame.
So this patch makes GetStackFrameCount always return the full count, suspending interruption. I also went through all the places that use GetStackFrameCount to make sure that they really needed the full stack walk. In many cases, they did not. For instance frame select -r 10 was getting the number of frames just to check whether cur_frame_idx + 10 was within the stack. It's better in that case to see if that frame exists first, since that doesn't force a full stack walk, and only deal with walking off the end of the stack if it doesn't...
I also added a test for some of these behaviors.
Is the range inclusive of end_idx? as in, is it [0, end_idx) or [0, end_idx]?