Better step return strategy for x86 binaries in native windows debug adapter

Right now the native windows debug adapter uses the same strategy to do step return, i.e., placing a breakpoint at the return address and then resumes the target. While this works fine, the stack frame information returned by StackWalk function is often times inaccurate, causing the target to behave unexpectedly in various cases, e.g., in #421

There are a couple of ways to deal with. To start with, we can use binja's analysis to find return instructions and put a breakpoint on all of them. However, this does not work well for recursion. Similarly, we can consider breakpoint on ret, then continue until the stack pointer is larger, though it might break in case of tailcalls. A different way to leverage binja's analysis is since binja knows the stack pointer offset from the entry (return address) at every point in the function via LLIL stack pointer, we can find the return address on the stack and then put a breakpoint there

For context, x64dbg does step over until a return instruction is encountered

Start by locating the native Windows debug adapter's current step-return implementation and its use of StackWalk. Read the x86 step-return behavior and the Binja LLIL stack-pointer information, then compare the proposed approaches, including recursion and tailcalls. Done means a reliable return strategy that avoids the inaccurate stack-frame behavior described here.