Support importing modules (module alias imports)

# Problem

Currently, use only supports importing symbols from modules (and `*` globs). It is not possible to import a module itself and then refer to it as a namespace.

Example that does not work today:
```
use deep::deeper;

deeper::symbol
```

At the moment, `UseTree::Name(path)` is always interpreted as “import the last segment as a symbol from its parent module”, so `use deep::deeper` is treated as a symbol import instead of a module alias.

# Goal

Support module alias imports, similar to Rust:
```
use deep::deeper; // introduces local name `deeper`
use deep::deeper::mod1; // introduces local name `mod1`
```

So that qualified paths starting with the alias are resolved correctly.

# Proposed minimal approach

1. Extend `Use` (in `uses.rs`)
* Add a new variant, e.g.:
```
Use::Module { alias: Ustr, target: Path, span: Location }
```
* `alias` is the locally introduced name.
* `target` is the full module path.
2. Resolve module imports in `import_resolver.rs`
* When flattening `UseTree::Name(path)`:
* If the full path refers to a module → create `Use::Module`.
* Otherwise, fall back to existing symbol-import logic.
* This requires extending `ModulesResolver` with:
```
fn module_exists(&self, module: &Path) -> bool;
```
3. Path resolution changes
* When resolving a qualified path like `x::y::z`:
* If `x` is a module alias imported via `Use::Module`, rewrite the path to `::y::z`.
* Then continue with normal resolution.
* This likely lives in `ModuleEnv` or wherever multi-segment paths are resolved.
4. Conflict handling
* Module alias imports introduce a local name and should:
* conflict with local definitions of the same name
* conflict with other imports (symbol or module) introducing the same name
* participate in existing duplicate-import detection

# Non-goals (for now)
* No reexports (`pub use`-style behavior)
* No `as` renaming (can be added later)
* No assumption that partial paths are modules unless they actually exist in the module table

# Status
* Import resolution infrastructure (`import_resolver`, conflict detection, glob handling) is in place.
* Unit tests exist for symbol imports and glob conflicts.
* Module alias imports are intentionally deferred to keep the current change minimal.