Redo dependency management

So I just had to update every single submodule in dappsys again since there was a one char change in `ds-test` and I just can't go on like this :sweat_smile:. Just wanted to get some ideas down for now as to the best way forward.

As I see it the biggest issue with out current dependency management setup is the way that `dapp remappings` forces a consistent version for each package in the dependency tree, resulting in a huge maintaince overhead every time a change to a low level dependency is made.

There are however many nice features about the current approach:

- federated: A package can be stored on any git host
- immutable: The hash of the package content is commited to in the git log
- auditable: Any version change is reflected in the commit. Dependency source code is available in the same repo as the top level project, and can be grepped through with ease.

How can we keep these nice features, while removing the pain associated with `dapp remappings`? I can see a few options:

### Remove dapp remappings

The remappings make imports a little prettier, but we could get by just fine by using relative or absolute imports. This would keep all of the nice features, be almost no effort, and allow many package versions to exist in the same package tree.

The downsides are that this is a breaking change, and that imports wouldn't look so clean.

### Expand dapp remappings

We could modify the import syntax supported by dapp remappings to allow users to specify a specific version, e.g. `import "ds-test/test.sol@` where `VERSION` is a reference to a git object (e.g. commit hash, branch or tag ref). This would allow uniquely specifying a specific package version in dependency tree. There is probably quite a lot of work involved to figure out the specifics here.

This has the advantage of being backwards compatible and keeping clean imports, but it is quite a lot more work, and makes the dapp import syntax even more non standard, meaning users of other frameworks will have an even harder time consuming packages that have been created with dapp.

### Full nixifification

We could start to more heavily leverage nix for dependency management. This would keep most of the advantages above (although grepping through dependency source would probably get harder), while also potentially allowing for nice features like parallel builds and multi compiler support. It's not super clear if we would be able to use nix to avoid the remappings issue. This would also be a huge breaking change and would tie us forever to nix as a runtime dependency, which may not be desirable.

Start with the current dapp remappings behavior and trace how it enforces one version per package in a dependency tree. Compare the three alternatives in the issue, then define a chosen design, compatibility expectations, and validation criteria that preserve the listed federation, immutability, and auditability goals.

Written by the indexing model from the issue text.