Module dependencies: use standard dagger.lock

Context

A module manifest can declare "runtime dependencies": other modules that the engine should pre-load and serve to the loaded module when it opens client connections. This feature will become deprecated in the future v2 module manifest (instead each client will load their respective dependency dynamically and lazily).

Problem

As currently implemented, module runtime dependencies carry their own pins. So dagger-module.toml acts as its own lockfile, independently of the user's own dagger.lock. So there are 3 lockfiles involved:

1. dagger.lock in workspace A, where the upstream module is developed (dagger mod client add...)
2. dagger.lock in workspace B, where the upstream is installed (dagger mod install...)
3. dagger-module.toml developed in workspace A and loaded in workspace B.

This is too complex. It's difficult to keep these files in sync reliably; difficult for users to understand the lifecycle and not make mistakes; difficult for SDK developers to implement it correctly; and will break with client unification, which deprecates runtime dependencies altogether.

Solution

• 1.0.0-beta.12 (now): remove dependencies.*.pin from dagger-module.toml. Dependency address is written to dagger-module.toml exactly the same as upstream dagger.toml. To control version, module devs should use version constraints. Exact pins are written in downstream dagger.lock. If a developer really needs a specific commit, they can just use the ref as version

• unification (soon): Stop using dependencies altogether in dagger-module.toml. Same lifecycle.

• Later: if module devs need more control, we can add a feature allowing modules to ship with an overlay lockfile (same format). But that can wait, not a one-way door