Add a "context" hook for generic calls during codegen

[Keno]

This adds a new context field that rewrites generic calls like
apply_generic(f, (args...,)) to apply_generic(context, (f, args...))
during codegen. The intention here is to allow external AbstractInterpreters
to provide custom implementations of apply_generic (usually recursing
analysis using the same interpreter, but other behavior may be
desired). This is a bit of a stopgap solution. I think in the fullness
of time, we'll probably want completely custom codegen for generic
callsites, to avoid the potential of a double-dispatch impact, but
for the moment this allows prototyping.

[vtjnash]

This seems likely to break rather often, since it's already only one of many places where the internal system may call into jl_apply_generic (any invoke site may get turned back into a trampoline sometimes, as well as the reverse may happen). It's not bad, but I wonder why you don't do it as a post-processing step. Regardless, since I assume this to be documented as unstable/experimental, that doesn't need to block merging.

It looks like the only thing it requires for merging is to be added to the list of all parameters inside compare_cgparams.

[Keno]

It's not bad, but I wonder why you don't do it as a post-processing step.

I was hoping to be able to avoid relying on LLVM.jl at least for the simple cases. It'll likely be required in full generality, but it's pretty nice to be able to just write the hook in regular Julia without having to do all the low level code generation for prototyping.

[vtjnash]

True, I suppose a pre-processing step is more sensible, while semantic meaning is still clearer in the IR?

[Keno]

Right, I don't want to transform it in the Julia IR, because the fact that it's a generic call doesn't matter there. From the julia perspective it's just a regular call - it's about the implementation detail of how that call gets dispatched and for a custom AbstractInterpreter that may require something other than the Julia default - but it's semantically still just a regular abstract call. It does make sense to transform at the LLVM level of course, but this just seems like an easier way to achieve that end.