Previously, all imports were available in the header, so we could start
processing dependencies as soon as we parsed it. However, the new imports
are treated as defs, so we have to parse the whole module to find them.
This commit essentially moves the dependency resolution from the `LoadHeader`
phase to the `Parse` phase, and it updates canonicalization to introduce
module symbols into scope when a `ValueDef::ModuleImport` is encountered.
NOTE:
- The `imports` header still parses, but it's no longer wired up. I will remove
it in an upcoming commit.
- Ingested files and imports that appear in nested expressions are not
yet supported by load
The algorithm for solving recursive definitions proceeds in several
steps. There are three main phases: introduction of what's known,
solving what's not known, and then checking our work of what was
inferred against what the programmer claimed. Concretely:
1. All explicitly-annotated signatures in the mutually recursive set are
introduced and let-generalized.
2. Then, inference type variables (`_`) and unannotated def signatures are
introduced to the cycle, without generalization. The bodies of these
defs, that are either unannotated or have inference variables, are
solved.
3. The defs from step (2) are now let-generalized, since we now know
that their types are consistent. At this point, all the defs in the
cycle have their types introduced and let-generalized, but we still
haven't checked the bodies of the defs froom step (1).
4. Check the bodies of explicitly-annotated defs in recursive set. This
might materially affect the actual types in the signature, for
example do to fixpoint-fixing or alias expansion.
5. As a result of (4) possibly changing the structure of the annotated
type, and because the previous annotated types in (1) were introduced
at a lower rank, we now re-introduce and re-generalize the solved def
types, in the same we did in step (3).
5. The rest of the program is solved.
Now, a very important thing here is that the annotation signature
introduced for (1) consists of different type variables than the
annotation signature introduced in (5). The reason is that they live at
different ranks. Prior to this patch we were not explicilty doing so;
this commit ensures that we do.
