allow CodeInfo to be returned directly from generated function generator

[jrevels]

My pitiable attempt at resolving #21146. I'm not a C programmer by any means, so I've probably done something stupid/silly.

I would appreciate any direction here, since if I can get it working, this would be quite useful for tracing generic Julia calls via dispatch-interceptable function wrappers.

[jrevels]

What work items are left for this PR (besides tests)? I know there needs to be some sort of validation pass over the emitted CodeInfo, but I'm not sure what the pass should be checking for exactly. The only guarantees we normally ascribe to Expr generated bodies are that they're locally syntactically valid, yeah?

[StefanKarpinski]

@JeffBezanson, any thoughts on this? Even if just uncertainty, would be good to know...

[vtjnash]

This is legal for inference to do, so that basically makes it certain that generated functions are allowed to do it. We haven't done it before mostly because creating a valid CodeInfo object is fairly difficult (it's easy to trick yourself into thinking some transform is valid which is not).

[JeffBezanson]

Agreed, the concept is legit.

[StefanKarpinski]

Does that mean we should merge this?

[jrevels]

Added a fairly simple test for this. If anybody has other test ideas, let me know and I can take a crack at implementing them.

I'm planning on implementing a (naive) IR validator in a separate PR, which would make this feature somewhat more robust/error-prone. I'm fine with the IR validator being either a prerequisite or follow-up PR to this PR; otherwise, this PR is ready to merge if CI comes up green.

[jrevels]

Given that the only issue here seems to be a lack of CodeInfo validation, my plan is to merge this as soon as #22938 is merged (assuming nobody expresses dissent).

[JeffBezanson]

I'm ok with merging in either order.

[jrevels]

I'll merge this now, then, since we've decided in #22938 the code validator won't be enabled by default anyway.