Remove arraylist_t from external native code APIs.

[maleadt]

GPUCompiler.jl used to rely on calls to the lookup function (mapping MIs to CIs) to keep track of MIs used during compilation, which Enzyme.jl then uses for... whatever it does. After #54899, the IR already contains CIs, resulting in this not being reliable anymore, as the lookup callback isn't invoked for every CI anymore.

I noticed that we already had accessor functions for fetching the list of MIs involved in a native compilation, jl_get_llvm_mis, however these functions currently use arraylist_t objects that are not usable to external consumers like GPUCompiler.jl. This PR switches those APIs over to a more traditional C style, passing pointers to the number of elements and the underlying data.

I guess it may be better for Enzyme.jl to consume CIs instead of MIs so that we don't need to maintain this mapping, but I focussed first on making the existing logic work again, and generalizing the current APIs doesn't seem to have much of a drawback.

[maleadt]

But why? These functions are used in staticdata.c, so in C code. Using Array's from there doesn't work, and I don't see the value of using a Memory only to then just have to copy data out into the arraylist_t functions that already live there (such as jl_rebuild_methtables).

[gbaraldi]

Yeah in a second thought I realized that it would be annoying, so I just deleted my comment 😄

[vtjnash]

LGTM. It used to be arraylist_t was a good way of expressing this, since C still doesn't have this ability in the stdlib :/