[IRBuilder] Accept Module instead of LLVMContext in ctor (#229430)

This adds new constructor overloads, which accept `Module &` instead of
`LLVMContext &` in the ctor, and replaces nearly all usages of the old
constructors. A few more complicated cases (C API, SandboxIR context and
one unit test) are left alone for now.

The intent is to remove the old LLVMContext constructors and make
availability of the Module required at time of construction (either
directly passed to the ctor or implied by the insertion point).

The motivation for this is to ensure that IRBuilder always has an
available DataLayout. IRBuilder used to be DL-agnostic, but at this
point we've accumulated a number of key places which require a data
layout, and get it from the insertion point instead. This is not great,
because the insertion point is not actually required to be set when
producing instructions (they just won't be inserted).

Additionally, not having a required DataLayout also introduces the
ConstantFolder (default) vs TargetFolder dichotomy, and is also a big
part of the reason why we still have separate ConstantFold and
ConstantFolding APIs that differ in DL-awareness.

Rather than accepting LLVMContext + DataLayout, this PR proposes to
accept Module instead. This is both a matter of convenience, but also
some future-proofing: For example, if we decide that constant
expressions should be owned by the Module instead of LLVMContext (which
they should be...) it will be easier to make such a change in the
future. Additionally, we have API's like
`IRBuilder::CreateGlobalString()`, which currently accept an explicit
Module, because IRBuilder itself is not module-aware.