Plafer mast library compilation

[plafer]

Implements follow-up to #1370, as detailed in #1226 (comment).

[bobbinth]

If compiled modules are added to the module graph "up-font" (i.e., at construction time), the probably won't make it into the pending module set and may not need to have special handling for compiled modules here.

[plafer]

I think removing the pending set is intricately linked with #1416. The main issue right now is with module rewriting here, which is the only reason why we need pending modules to be Box<Module> instead of Arc<Module> (i.e. we need ownership to be able to mutate it). I am also assuming that using Arc<Module> in our public API is a requirement.

But all this module rewriting goes away if we only allow modules to be added all at once, and the graph to be "recomputed" only once (which can be done with #1416). And then removing the pending module list becomes easy.

[bobbinth]

I think incremental additions of AST modules is something we may want to keep in the public API, but since we generate the output only once, we probably can do the "recompute" part only once as well. So, basically:

• All compiled modules are added at construction time.
• AST modules can be added one-by-one, but nothing is recomputed at this point.
• When the user calls assemble_program(), assemble_library() etc. the graph is computed and this happens only once.

And yes, I agree this is something to be done in/after #1416.

[bobbinth]

Looks good! Thank you!

[bobbinth]

Note for the future: if two procedures have the same MAST root, they would always have the same number of locals (because changing the number of locals would change the MAST root). So, if the number of locals differs somehow between two procedures with the same MAST root, one (or both) of them have incorrect number of locals in the metadata.