inference: don't infer const ABI for OpaqueClosure methods

[topolarity]

This IR is always destined for compilation, so the const ABI for these methods is not really useful.

This resolves part of #54377

Specifically, this is fast now:

foo() = Base.Experimental.@opaque Tuple{Float64}->_ x -> 0.0
bar() = Base.Experimental.@opaque Tuple{Float64}->_ x -> x

const oc1 = foo()
const oc2 = bar()

using BenchmarkTools
@btime sum(oc1, 1.0:100.0) # PR: 197.571 ns (0 allocations: 0 bytes)
                           # (compare to master: 2.932 μs (200 allocations: 6.25 KiB))
@btime sum(oc2, 1.0:100.0) # PR / master: 208.488 ns (0 allocations: 0 bytes)

The original MWE with the @opaque at toplevel is unfortunately still slow, because it does not get generated at compile-time and jl_new_opaque_closure currently does a poor job of enforcing its desired ABI.

[aviatesk]

The original MWE with the @opaque at toplevel is unfortunately still slow, because it does not get generated at compile-time and jl_new_opaque_closure currently does a poor job of enforcing its desired ABI.

Maybe we should force compilation on top-level thunks containing :jl_new_opaque_closure exprs?

[vtjnash]

Seems an acceptable workaround for now, though it seems entirely incorrect for codegen to be unable to handle this. The presence of source code in the form of a CodeInfo in the inferred field is merely an unreliable implementation detail, and not some that can be safely accessed from CodeInstance by codegen.