Make Expr(:invoke) target be a CodeInstance, not MethodInstance

[vtjnash]

This is a look at what is necessary and what it would look like for codegen to be using CodeInstance directly to get the API for a function call (specifically the rettype), rather than using a lookup call at that point to decide upon the API. It is based around the idea that eventually we would keep track of these anyways to form a graph of the inferred edge data, for use later in validation anyways (instead of attempting to invert the backedges graph in staticdata_utils.c), so we might as well use the same target type for the :invoke call representation also.

This does not depend upon #54894, but is much better with it. It did depend upon #54738, though there still remains work to do to teach it how to select a correct alternative CodeInstance after deserializing. Also still to do: codegen also should be looking for equivalent objects, not just using the exact one given, per the definition of equivalency in https://hackmd.io/@vtjnash/codeinstances (and that is what precompile should be doing also).

Depends on #56552, #56551, #56547, #56598

[vtjnash]

This should be ready to go now, since it seems working, it would be nice to merge before it picks up spurious conflicts.

@nanosoldier runbenchmarks(!"scalar", vs=":master")

Some improvements can be done later:

• jitlayers/aotcompile/staticdata should be looking for equivalent objects instead of deferring that entirely to the runtime (as a jl_invoke)
• conversely, interpreter should be trying to execute the object directly, instead of immediately looking for an equivalent one
• non-nothing owner needs special handling implemented (currently it is still illegal to expect to put a different owner there), since codegen may become inconsistent and incorrect

[Keno]

@vtjnash small conflicts with my worldage PR, so I rebased this for you, just FYI

[nanosoldier]

Your benchmark job has completed - possible performance regressions were detected. A full report can be found here.