Update LLVM C API usage and remove hand-rolled code

[andrew-wja]

Since anyone last touched our FFI layer, the LLVM C API has been updated significantly. Most importantly, the LLVM C API now has functions which do things for which we have hand-rolled code in our FFI.

Where the LLVM C API now has a function that does something, and we have hand-rolled code that does something, we should remove our hand-rolled code and instead call the LLVM C API function.

This is quite a large undertaking, effectively being an audit of the entire FFI layer. However, it can be done piecewise, module-by-module.

This will result in our FFI layer becoming quite a lot smaller and simpler, which will make it easier to maintain going forward. It also reduces the likelihood of something breaking dues to a change in upstream LLVM, since we can assume that the LLVM project will ensure that their own C API is working.

[andrew-wja]

There are also places where we have an awkward division between our C/C++ code and Haskell. For example, there are many instances where we have FFI wrapper functions written in C++ which are themselves doing work using the LLVM C/C++ API. Arguably, we should be wrapping the more primitive C API functions which are being called, and doing that work in Haskell instead. Otherwise, we are effectively extending the LLVM C API with our own handwritten extra stuff, which is liable to break if the LLVM C API is updated.

A simple example is in the module LLVM.Internal.FFI.Assembly and in the corresponding AssemblyC.cpp file. In this instance, we could bind the C API function LLVMParseIRInContext, and make the function parseLLVMAssembly a Haskell function rather than have the logic inside the FFI wrapper function. This is a very trivial example, but there are other FFI wrapper functions doing a lot more work in C++.