Incomplete ELF support

[d-e-s-o]

It appears as if the ELF parser does not handle all possible values of e_shstrndx correctly:

https://github.com/libbpf/blazesym/blob/master/src/elf/parser.rs#L192-L207

ELF(5) states:

       e_shstrndx
              This  member  holds the section header table index of the entry associ‐
              ated with the section name string table.  If the file  has  no  section
              name string table, this member holds the value SHN_UNDEF.

              If  the  index  of  section name string table section is larger than or
              equal to SHN_LORESERVE (0xff00), this member holds SHN_XINDEX  (0xffff)
              and  the real index of the section name string table section is held in
              the sh_link member of the initial entry in section header table.   Oth‐
              erwise, the sh_link member of the initial entry in section header table
              contains the value zero.

So we may have to special case SHN_XINDEX.

[danielocfb]

Our string lookup logic is also questionable. See https://github.com/libbpf/blazesym/pull/190#discussion_r1212089043

[danielocfb]

For reference, over in https://github.com/libbpf/blazesym/pull/384#pullrequestreview-1709204144 the following case was also mentioned:

For extended program header table numbering the scheme is similar, with the e_phnum field of the executable header holding the value PN_XNUM (0xFFFF) and the sh_link field of the zeroth section header table holding the actual number of program header table entries.

[danielocfb]

We should also check what happens when there are more than 0xffff sections and we try to access one via the Elf64_Sym.st_shndx member (which is 16 bits in size). See https://github.com/libbpf/blazesym/pull/389#discussion_r1379425619