Possible fix for overly long stack trace on Windows

Native stack trace outputted on server crash can be far longer than
it actually is, containing lots of invalid entries (bad return addresses
that are not within any image) after the valid ones. For example:

http://forum.sa-mp.com/showpost.php?p=2492685&postcount=3
http://forum.sa-mp.com/showpost.php?p=2131252&postcount=1
http://forum.sa-mp.com/showpost.php?p=2361518&postcount=3
http://forum.sa-mp.com/showpost.php?p=2383963&postcount=6
http://forum.sa-mp.com/showpost.php?p=2051019&postcount=1

Interestingly enough, the invalid entries seem to show up after a negative
return address is encountered among them (e.g. ffc30000). This can be
used  to detect the start of the invalid part, so rather than checking
whether the return address returned by StackWalk64() is 0, we can stop at
the point where it's <= 0.

(What is more interesting is that in all cases StackWalk64() goes crazy
after the magical address ffc30000 - maybe it means something special?).
Fix EIP frame always having no symbol name on Windows

Re-structure the stack walking loop so that the EIP frames is no
different from other frames. Previously it was pushed separately
prior to this very loop, omitting symbol name lookup.