RFC: allow precompile to associate a MethodInstance with a module

[timholy]

Suppose we have a package that does this:

module MyPkg

struct T end

if ccall(:jl_generating_output, Cint, ()) == 1
    precompile(setindex!, (Dict{T,Int}, Int, T))
end

end

Unfortunately, the precompile does nothing useful. I dove into this in some detail. It appears that the reason is that no setindex! methods are defined in MyPkg, and consequently the corresponding binding b has b->value == NULL. As a consequence it doesn't get added to the *.ji cache file.

This is unfortunate, because inferring setindex! for Dicts is quite expensive. This PR aims to fix that by allowing package authors to write

    precompile(MyPkg, setindex!, (Dict{T,Int}, Int, T))

Note the module argument in the first slot. This adds it to a list of MethodInstances that should be associated with MyPkg.

I've verified it doesn't break anything, but it doesn't yet work. I tried the instructions here but gdb complains

(gdb) attach -w -n julia-debug
Illegal process-id: -w -n julia-debug.

Perhaps someone who knows more about this than me can offer some helpful tips.

I am not sure this alone will suffice, but I suspect that perhaps in conjunction with just a few other tweaks (and good ways to measure time spent on inference, see #31444 and this SnoopCompile branch) we could dramatically cut latencies for certain packages. CC @SimonDanisch, who I know is very interested in the topic.

[maleadt]

Fixes part 1 of #23548?

[timholy]

Yes, that's basically right. Together with that SnoopCompile branch you'll also get diagnostics on what "top-level callers" (top-level not in the sense of scope but in the sense of recursive calls) take the most time, and hence are most in need of precompilation. Finally, if it does work recursively it should also cover kwfunction body-methods. If that doesn't happen automatically, then I now have enough understanding of lowered code to find the methods that need to be covered. See #30908, LoweredCodeUtils, and particularly LoweredCodeUtils.bodymethod.

Bottom line is, if @vtjnash would be willing to spend a little time talking to me about this and tutoring me on some of the more opaque parts of this, I think we can fix this longstanding problem.

[vtjnash]

Closing, since this is just a no-op. Something like #32705 is required instead.