Rewrite DWARF inlined subroutine handling to work cross CU

Rewrite DWARF inlined subroutine handling to work cross CU

The readdwarf3 parsers cannot read DIEs across CUs. An inlined
subroutine refers to an subprogram which has a name (or refers to a
declaration of a subprogram that has a name). These subprograms can be
(and often are when dwz has been used to compress the DWARF) in a
different CU. So a lot of inlined subroutines in backtraces are just
called "UnknownInlinedFun".

To work around not being able to read DIEs across CUs directly we
don't try to immediately resolve the name of the inlined subroutine by
following the abstract origin reference to the subprogram, but just
record it in the DiInlLoc. We also record all subprogram indexes while
parsing in a new DiSubprogram structure and whether the subprogram had
a name or had a reference to another subprogram (specification).

We have to look under a couple more DIEs. We normally want to skip any
DIE that doesn't have an address range when looking for inlined
subroutines, but there are various other DIEs that can contain a
subprogram (specification).

We also want to walk the DIEs from low to high (cooked DIE) index, so
we first pass over the main .debug_info, then the .debug_types, and
finally the alt .debug_info. That way we can store the DiSubprograms
in an array from low to high index and use a binary search to connect
the inlined subroutines to the subprogram that contains the name.

The code also tracks whether the subprogram is artificial, but this
isn't used yet. But should make it possible for a followup patch to
remove artificial inlined subroutines from a backtrace.

Tested against emacs and libreoffice as packaged in Fedora where the
programs and all shared libraries used are processed with dwz. The new
code gives a name to every inlined subroutine. Except when the DWARF
produced is bad and the DW_AT_subroutine didn't contain an
DW_AT_abstract_origin and so no DW_AT_subprogram can be found.

https://bugs.kde.org/show_bug.cgi?id=338803