Fix a bug in `dbg` expression desugaring by using the module scope to
generate unique identifiers instead of the variable store.
In the initial implementation of `dbg` expressions we used the
`VarStore` to generate unique identifiers for new variables created
during desugaring. We should have instead used the current module's
`Scope`, which handles identifiers within the module. Each scope has its
own incrementing variable count which is independent of the shared
variable store. The scope is used to generate new identifiers at other
points in canonicalization, such as when assigning a global identifier
to closures and `expect`s. It's possible that the identifier generated
for `dbg` could conflict with an identifier generated by the scope,
resulting in a confusing error.
We were still passing `ModuleIds` from `load` to `can`, but now
that imports can appear in any scope, we don't know which package
an unqualified module name belongs to from the top level.
We now pass `PackageModuleIds` instead and keep a Map of `ModuleName` to
`ModuleId` in `Scope`.
This also allow us to import multiple modules with the same name from different
packages as long as a unique alias is provided.
Allows a module to be imported with an alias:
import JsonDecode as JD
Import aliases must be unique and they cannot have the same name
as an imported module.
After parsing a module, we now recursively traverse the tree to find
all imports inside Defs, not just the top-level ones.
Previously, imported modules were available in the entire file,
but that's no longer the case. Therefore, Scope now keeps track of
imported modules and Env::qualified_lookup checks whether a module
is available in the provided scope.
Note: Unused import warnings are still global and need to be updated.
