for unknown reasons gdb seems to behave inconsistently here. usually
'at' denotes a file, but there are backtraces where it doesn't
I've add a trivial suffix check to ensure parsing of these lines works
correctly even when 'at' is used in combination with a library name.
this is a bit hackish, but in reality this entire parsing tech should
probably be replaced by a python plugin for gdb so we can get interactive
access to the frames and serialize them in a well defined format instead of
having to parse "random" text
on top of that our regex assumed we'd always have a function name, which is
also not true as that bug report shows. to mitigate this the matching group
has been made optional.
this commit also adds a test for the gdb line parsing unit with some
obvious line samples I could find just now