On Windows we can sometimes encounter threads stopped in locations for
which we do not have entries in debug_frame.
These cases seem to be due to calls to Windows API in the go runtime,
we can still produce a (partial) stack trace in this circumstance by
following frame pointers (starting with BP).
We still prefer debug_frame entries when available since go functions
do not have frame pointers before go1.8.
The PC we have is relative to the first instruction after the CALL
instruction currently being executed.
Anyone watching a disassembly will understand what's happening if we
report the return PC, but reporting the first PC of the current line is
useless and confusing.
