Allocate GOT/PLT slots into one shared section deterministically

[quic-areg]

Previously, every target created its own .got/.got.plt/.plt per input object
file and relied on section merging to stitch them back together. This PR instead
creates them once in a shared section and places every slot there, and makes the
slot order deterministic.

.rela.dyn and .rela.plt are created once alongside .got/.plt rather than per
input file.

Slots are now created during relocation scanning deterministically in input
order, matching lld. The scan is now serial. Slot creation within it was already
serialized on a mutex, so parallelism only decided which input reached the lock
first.

ifunc loops now iterate .plt instead of a DenseMap, which is not deterministic
even under a single-threaded link.

[Shankar Easwaran (quic-seaswara)]

A few questions before I do a full review.

From the PR description:
The scan is now serial. GOT slot creation within the scan was already serialized by a mutex, so the previous parallelism only affected which input acquired the lock first.

=> The GOT slot will still be created by whichever input reaches it first, which means the behavior remains non-deterministic.

Regarding the GOT/PLT design, they still allocate fragments on a per-GOT-slot and per-PLT-slot basis. What I was proposing instead is:

• A single GOT fragment that contains multiple GOT slots.

• A single PLT fragment that contains multiple PLT slots.

In this model, the individual slots would be private regions within their respective GOT or PLT fragment, rather than each slot being represented by a separate fragment.

This would eliminate fragment creation ordering as a source of non-determinism and provide a more natural representation of the GOT and PLT structures.