Add DT_NEEDED dependency injection

[ProjectSynchro]

Builds on #48. This PR is stacked on it, so the diff to look at is just the injection commits on top.

Adds ElfFile.AddNeededLibrary(name), which injects a DT_NEEDED dependency into an existing dynamically-linked image so the loader loads that library at startup. It's essentially patchelf --add-needed as an in-process .NET API.

What's new

ElfFile.AddNeededLibrary(string libraryName). It's address-preserving: no existing section changes byte offset, so existing symbols, relocations and code stay valid. The mechanism is the same idea patchelf uses:

• Grows .dynstr with the new name and adds a DT_NEEDED entry.
• Relocates the .dynamic and .dynstr sections to end-of-file, backfilling the space they vacated with equal-size padding so every other section keeps its offset.
• Maps the relocated region with a new PT_LOAD built from a spare PT_NOTE program header, so the program-header table doesn't grow.
• Repoints PT_DYNAMIC, DT_STRTAB/DT_STRSZ, and the _DYNAMIC symbol at the new location.

Because the sections move (not just the segment), section and segment stay consistent:
Both readelf -d and a LibObjectFile re-read see the injected dependency. You can use that to check whether a binary is already patched, so re-running the injection is a no-op.

Trade-offs / limits (documented and enforced with diagnostics)

• Requires a PT_NOTE to repurpose and a PT_DYNAMIC (a dynamically-linked image). If either is
  missing it throws rather than producing a broken file.
• The repurposed PT_NOTE's contents (e.g. the build-id note) drop from the load image.
• The original .dynamic/.dynstr bytes stay in the file as padding. This is the same trade-off patchelf makes.

Tests

• In-process: injecting into a real shared object repurposes a PT_NOTE into a PT_LOAD, moves PT_DYNAMIC, and resolving DT_NEEDED the way the loader does (PT_DYNAMIC -> DT_STRTAB) shows existing dependencies preserved and the injected one resolvable, and the section view agrees with it. Plus rejection of a non-dynamic file.
• Verified in the docker test image: a patched executable and a dlopen'd shared object both load and run with the injected library's constructor firing, and eu-elflint seem happy versus the original binary.

[xoofx]

Thanks!