Refactor handling of global initializers

GHC uses global initializers for a number of things including cost-center registration, info-table provenance registration, and setup of foreign exports. Previously, the global initializer arrays which referenced these initializers would live in the object file of the C stub, which would then be merged into the main object file of the module.

Unfortunately, this approach is no longer tenable with the move to Clang/LLVM on Windows (see #21019 (closed)). Specifically, lld's PE backend does not support object merging (that is, the -r flag). Instead we are now rather packaging a module's object files into a static library. However, this is problematic in the case of initializers as there are no references to the C stub object in the archive, meaning that the linker may drop the object from the final link.

This patch refactors our handling of global initializers to instead place initializer arrays within the object file of the module to which they belong. We do this by introducing a Cmm data declaration containing the initializer array in the module's Cmm stream. While the initializer functions themselves remain in separate C stub objects, the reference from the module's object ensures that they are not dropped from the final link.

In service of #21068 (closed).

To do

• Handle finalizers as well (necessary for static pointer table deregistration)
• Handle LLVM backend (see https://llvm.org/docs/LangRef.html#the-llvm-global-ctors-global-variable)
• Write a Note describing the story