Moved `Contents` and `Fixups` SmallVector storage to MCSection, enabling
trivial destructors for most fragment subclasses and eliminating the need
for MCFragment::destroy in ~MCSection.

For appending content to the current section, use
getContentsForAppending. During assembler relaxation, prefer
setContents/setFixups, which may involve copying and reduce the benefits
of https://reviews.llvm.org/D145791.

Moving only Contents out-of-line caused a slight performance regression
(Alexis Engelke's 2024 prototype). By also moving Fragments out-of-line,
fragment destructors become trivial, resulting in
neglgible instructions:u increase for "stage2-O0-g" and [large max-rss decrease](https://llvm-compile-time-tracker.com/compare.php?from=84e82746c3ff63ec23a8b85e9efd4f7fccf92590&to=555a28c0b2f8250a9cf86fd267a04b0460283e15&stat=max-rss&linkStats=on)
for the "stage1-ReleaseLTO-g (link only)" benchmark.
(
An older version using fewer inline functions: https://llvm-compile-time-tracker.com/compare.php?from=bb982e733cfcda7e4cfb0583544f68af65211ed1&to=f12d55f97c47717d438951ecddecf8ebd28c296b&linkStats=on
)

Now using plain SmallVector in MCSection for storage, with potential for
future allocator optimizations, such as allocating `Contents` as the
trailing object of MCDataFragment. (GNU Assembler uses gnulib's obstack
for fragment management.)

Co-authored-by: Alexis Engelke <engelke@in.tum.de>

Pull Request: https://github.com/llvm/llvm-project/pull/146307

... due to their close relationship. MCSection's inline functions (e.g.
iterator) access MCFragment, and we want MCFragment's inline functions
to access MCSection similarly (#146307).

Pull Request: https://github.com/llvm/llvm-project/pull/146315

Similar to b65760bc7fcdee8179bf1e57fce3786737528dd8 for ELF.

* Remove the MCAssembler * argument. Change subclasses to use MCAssembler *MCObjectWriter::Asm.
* Remove pure specifier and add an empty implementation
* Change MCFragment * to MCFragment &

We will replace the MCSymbolRefExpr member in MCValue with MCSymbol.
This change reduces dependence on MCSymbolRefExpr.

MCValue::SymB is a MCSymbolRefExpr *, which might become MCSymbol * in
the future. Simplify some code that uses MCValue::SymB.

Add the required IMAGE_REL_MIPS_PAIR relocation after
IMAGE_REL_MIPS_REFHI/IMAGE_REL_MIPS_SECRELHI

Microsoft PE/COFF specification says that the IMAGE_REL_MIPS_REFHI
relocation contains "the high 16 bits of the target's 32-bit virtual
address. [...] This relocation must be immediately followed by a PAIR
relocation whose SymbolTableIndex contains a 16-bit displacement which
is added to the upper 16 bits taken from the location being relocated."

Microsoft PE/COFF specification says that the IMAGE_REL_MIPS_SECRELHI
relocation contains "the high 16 bits of the 32-bit offset of the target
from the beginning of its section. A PAIR relocation must immediately
follow this on. The SymbolTableIndex of the PAIR relocation contains a
16-bit displacement, which is added to the upper 16 bits taken from the
location being relocated."

Behavior has been checked against Microsoft C compiler for MIPS.