Filter out methods that are unreachable from native AbsInt

[vchuravy]

While working on JuliaGPU/GPUCompiler.jl#557 I would sometimes get an error during package image creation

ERROR: The following 1 direct dependency failed to precompile:

GemmDenseCUDA 

Failed to precompile GemmDenseCUDA [77fe268f-d775-43f7-b4ca-0f4dd283d536] to "/home/vchuravy/.julia/compiled/v1.11/GemmDenseCUDA/jl_3sDnKv".
LLVM ERROR: Cannot select: intrinsic %llvm.nvvm.membar.sys

[26379] signal 6 (-6): Aborted
in expression starting at none:0
Allocations: 33542987 (Pool: 33542022; Big: 965); GC: 2

This confused me since we filter out compilation results for the foreign abstract interpreters.

The only method that creates this intrinsic is CUDA.threadfence_system and if I execute it locally
I get a similar error.

julia> CUDA.threadfence_system()
ERROR: LLVM error: Cannot select: intrinsic %llvm.nvvm.membar.sys
Stacktrace:
 [1] handle_error(reason::Cstring)
   @ LLVM ~/src/LLVM/src/core/context.jl:170
 [2] top-level scope
   @ REPL[2]:1
 [3] top-level scope
   @ ~/.julia/packages/CUDA/02Uw6/src/initialization.jl:206

Now there is an argument that CUDA should prevent the user from calling this function
(and indeed we have @device_function that errors at runtime)

Nonetheless I was still curious if we are by accident leaking. In the end we are not,
but if someone queues up a codeinstance through PrecompileTools and we will try and
lookup the method and re-infer it if necessary.

This PR filters out methodinstances that we only queue up because of a foreign abstract interpreter.

[vchuravy]

Talking with @maleadt I was a bit confused why the mi was scheduled since static int precompile_enq_specialization_(jl_method_instance_t *mi, void *closure) should have filtered it.