Make dwarf_init_path_a error non-fatal

[GHF]

I ran into an exception in the case of a "corrupted" ELF section (just unreadable by libdwarf, not corrupted). It turned out to be percolated from dwarf_init_path_a returning an error. libdwarf failing to parse an object should not inhibit falling back to parsing the ELF symtab, so I make this particular path less fatal.

I repeated ok = false; for consistency and readability but I do realize all of the appearances in the function of this line seem redundant.

[jeremy-rifkin]

Thanks for opening this, I think this presents a larger question of how error reporting in cpptrace should work and I'm not sure the best approach.

An error from dwarf_init_path means something is terribly wrong with the file (or libdwarf) and that's something that needs to be reportable, somehow (trace_dwarf is really for my own internal printbugging of things, it's hard-coded to false). We'd want this reported similar to other important errors like dbghelp stuff on windows etc.

Stack traces are complicated and there are a lot of things that can go wrong, cpptrace tries to gracefully recover from everything unless absorb trace exceptions is set to false. I'm in agreement that ELF symbol table fallback should always be done even if libdwarf encounters a fatal error.

Maybe cpptrace should never throw internally unless caught quickly. There's now an alternative means of error reporting in the form of an internal logging mechanism (on the dev branch). This would probably be good to start using more instead of exceptions / absorb_trace_exceptions.