Fix: imports

[acl-cqc]

Previously loadStmtsWithEnv was discarding the graph, but keeping the VEnv, from all previous modules (files). It was also reusing the same Namespace for each file....which in theory could lead to VEnv entries from earlier modules pointing to nodes in the graph from the current module.

Also change loadStmtsWithEnv to use combineDisjointEnv to protect against errors, and improve handling of failing compilation (which used to spit out some incomplete Hugrs) in test.

closes #13

[acl-cqc]

Update: I tried modifying main just to merge the old graph with the new in loadStmtsWithEnv, defining a new function combineGraphs that errors if the nodes have any common keys. This produces no new test fails, but occurs several times - always in merging the oldGraph with new, not kcGraph with the graph from the decl bodies. Specifically this happens for: teleportation, cqcconf, magic-state-distillation, klet, qft, rus, ising, vlup_covering, examples/arith (note there is also test/compilation/arith which is fine), imports. (All of these already xfailed for "other reasons"....)

So we could include that combineGraphs here to be defensive, but the sad thing is that we are combining graphs using <> which is just generic for tuples i.e. using <> for each element :(. Making Graph into an opaque ADT would be a good step but a lot of churn....

Also the combineGraphs error is not triggered in closures so still don't understand why that's fixed in the PR...

[croyzor]

I don't think this solves #96, but very likely that it is the problem behind #101!

[croyzor]

I've refactored combineDisjointEnvs a bit more to return a machine-usable error, which we can use to gather the FC in Load.hs (where we have the VDecl available - but not in checker). This could do with a test.

I'm struggling to come up with something where the error in Checker isn't raised first...