Factor out module-registry from AST func nodes

From discussion here and offline.

@ole.kruger wrote:

We resolve the association at the decoding. Imagine we run the decoder for the module_instances_encoding, which gives us a module_reg. Then we decode the top-level frame of our Eval.config - that decoder needs the resulting module_reg. With the resulting Eval.config we can disregard our module_reg, it is now captured within the values of Eval.config. The alternative, is to decode the module_instances_encoding and Eval.config without the knowledge of a module_reg. That means, you now need to pass the module_reg into every function that operates on the Eval.config. The result would be that passings of module_reg are now splintered across various functions and modules. To me passing an explicit module_reg to modules in Eval.* seems like a clear loss, because one can avoid it by resolving it entirely in the decoder modules. As a proportion, the code for evaluation which requires module_regs is much larger then that for the decoders.

So ultimately this is a trade-off, where do you pass module_reg around.

@jobjo wrote:

Right. I still think that avoiding duplicating information in the instance objects is more intuitive (and also simplifies the encoding somewhat). I understand that implies that Eval.* function are now “reader-monadic” and requires a module_reg environment to run. It makes it more explicit that this registry is only created ones. I’m fine to keep as is if it requires too much refactoring however. Can consider to push as a follow up (I might even take a look)