Removing the need for llvm_ext.cc

[HertzDevil]

If everything we need is already in LLVM's C API, then our build process will be considerably simpler (see for example #10880), and it'll become possible to build + distribute a Windows compiler that dynamically links against LLVM-C.dll without any LLVM static libraries.

The following list is mostly copied from #13177:

• LLVMExtDIBuilderCreateEnumerator
  LLVM 9.0.0 added LLVMDIBuilderCreateEnumerator. Our function is now conditionally compiled, but we cannot remove it completely as long as LLVM 8 is supported.
• LLVMExtSetCurrentDebugLocation
  This can mostly be replaced by LLVMSetCurrentDebugLocation in LLVM 8, and LLVMSetCurrentDebugLocation2 in LLVM 9+. LLVM 8 still needs the part of this function that clears the current debug location.
• LLVMExtWriteBitcodeWithSummaryToFile
  This is only needed for the now-removed ThinLTO support, and is now gone after Deprecate LLVM::Module#write_bitcode_with_summary_to_file #13488.
• LLVMExtBuildOperandBundleDef, LLVMExtBuildCall2, LLVMExtBuildInvoke2
  These will be available in LLVM 18 due to [LLVM-C] Support operand bundles llvm/llvm-project#73914.
• LLVMExtTargetMachineEnableGlobalIsel
  LLVM 18-dev added LLVMSetTargetMachineGlobalISel very recently in [llvm-c] Improve TargetMachine bindings llvm/llvm-project#70806.
• LLVMExtCreateMCJITCompilerForModule
  This is unnecessary since we could call the above function immediately after JIT compiler creation.

[HertzDevil]

As a final step, we need a way to tell the Makefile(s) that llvm_ext.obj doesn't need to be built at all and that the local compiler doesn't depend on it. This would happen if LLVM_VERSION is new enough, or if we explicitly disable it via a flag.

[straight-shoota]

With #14357 we can consider this resolved. llvm_ext is no longer necessary when linking LLVM 18+