lifter: read the ELF through LLVM instead of bfd, libdwarf and libelf

[o2alexanderfedin]

What

Reads the ELF through llvm::object::ELFObjectFile and llvm::DWARFContext instead of
binutils, and fixes a function-sizing bug that bfd's API had forced.

elflift linked three binutils libraries to do what LLVM already does and the lifter
already links: bfd to open the binary and walk sections and symbols, libelf for the ehdr,
program headers and symbol sizes, and libdwarf to recover function entries from .eh_frame
when the binary is stripped. All three go, and libiberty goes with them — it was only ever
bfd's transitive requirement. No LLVM library is added: LLVMObject and
LLVMDebugInfoDWARF arrive with the LLVM that remill already links.

Two commits, deliberately separate:

1. The port — byte-identical, which is its whole warrant.
Verified against the stock lifter in the :arm64 image, both loader paths, bitcode and wasm:

subject	path	funcs	bitcode	wasm
static, not stripped	.symtab	900	ec2dc6f9…	b15e9a6f… (5 654 545 B)
static, stripped	.eh_frame	899	883bbf48…	735ce583… (5 624 783 B)

The stripped arm matters: GetSblFromEhFrame — the entire libdwarf half — had never been
exercised by any check I could find, and LLVM's .eh_frame reader reproduces libdwarf exactly.

asection * becomes a small SectionRange (name/vma/size) owned by the loader. Containment
queries run over every section, unfiltered, because bfd's did — ELFSection is the wrong
type for that job since it drops sections based at 0x0. The LLVM objects sit behind a pimpl,
so no LLVM header reaches Loader.h, and TraceManager.h loses its <bfd.h>.

2. The sizing fix — this one changes output on purpose.
bfd's asymbol carries no size, so the loader re-read the ELF through libelf, built a
NAME → size map over .symtab and .dynsym, and joined on the name. That join is lossy.
On one static-glibc hello: 12 names collide and 15 function symbols get a length that is not
their own. The worst is free_mem — eight distinct static functions, of which seven receive
100 bytes in place of their real 36, 40, 48, 56, 104, 184 or 276, because the map keeps
whichever came last. TraceManager prefers the symbol size over section arithmetic, so the
lifter disassembled the wrong number of bytes for those seven. LLVM exposes st_size on the
symbol already in hand, so the workaround dies with the abstraction that forced it.

It is a second commit precisely because the first one's claim is "nothing changed", and the two
cannot both be true in one patch.

Evidence

• ninja test_dependencies && ctest: 2/2 pass, including the integration test that runs the
  lifted wasm under WasmEdge and matches Hello, World!.
• ldd on the built elflift: no bfd, dwarf, elf or iberty.
• Both artifacts also executed through an independent WASI runtime; each instantiates and runs
  _start to completion, and the pair reaches the same terminal state — different bitcode, same
  behaviour.

Notes

While writing this the first build was green, linked, emitted the right function count — and
produced wrong bitcode, because I admitted STT_GNU_IFUNC symbols on the strength of bfd's
source. The bfd in the build image does not flag them, so the original filter admitted none of
the binary's 10 ifuncs. Admitting them shifted every later symbol index by 10 and, through an
unstable sort over tied addresses, changed which alias named each lifted function — while the
count stayed identical. Worth knowing if anyone touches that filter: a count check does not see it.

Touches lifter/TraceManager.cpp, as does the amd64 front-end PR — if both are wanted, one
needs a trivial rebase on the other.