Modules for caching RGF ASTs vs resolving global symbols

[c42f]

In #20 I gave control to the user in which module they use for resolving symbols inside the RGF.

But I've now realized this could lead to precompilation issues if the user specifies a module for symbol resolution which is not the current module. As noted in SciML/ModelingToolkit.jl#681 (comment), there's actually two things that might be required separately:

• Ability to specify which module's precompile cache the RGF lives in.
• Ability to specify which module is used to look up global symbols used in that RGF (including generic functions)

#20 provides the second of these, but ignores the first. That makes it safe to use at runtime, but precompilation may be broken if the user uses a third party module.

I wonder what the best API is here for constructing RGFs. Perhaps we could provide:

# Use `mod` for both the cache and for lookup
RuntimeGeneratedFunction(mod, code)

# Use `mod` for symbol lookup, and `mod2` for precompilation cache
RuntimeGeneratedFunction(mod, code, precompile_in=mod2)

Alternatively we could decide we always want precompile_in=@__MODULE__ (this guarantees users won't have precompilation issues), and bring back the macro after all:

# resolve symbols in `mod`
@RuntimeGeneratedFunction(mod, code)

# resolve symbols in current module
@RuntimeGeneratedFunction(code)

Supporting different mod1 and mod2 would require an additional type parameter.

I guess I slightly favor the latter, so maybe we should revert #20. Thoughts?

[ChrisRackauckas]

If they need to precompile in the module in order for it to work well, then I think we just bring back the macro and do that.