When the operation for an unlock takes place in the config of a umbrella
application, the `unlock' provider does not see the dependency in the
`deps' value of the config (since it only includes the deps at the root
of the project) and ignores these.

Tests have broken as locks were expanded and auto-filled newer versions
of lockfiles. This fixes them back.

This commit replaces the method of upgrading by unlocking all transitive
deps by one that utilizes the parent element of each app to only
unlock transitive deps of children of the top level deps being upgraded.

Additionally the run function of upgrade_SUITE is modified to only create
the mock updates before the upgrade provider is run, instead of before
any provider is run, which would cause improper behavior in install_deps.

Requires a rework of other test suites using the same dep-handling
mechanism.

they would always be left unfound otherwise.

Lock forwarding is what happens when the file on disk are on a different
version from what is specified in the lock file. Files on disk should be
updated to respect what's in the lock file.

A negative test has been added so that lock files that are outdated vis.
the underlying git and packages but match files on disk do not get
forwarded. This job is left to the `upgrade' command.

- Track level of packages properly, they're not level 0 anymore (this
  could yield an issue where a src dep takes precedence over a pkg dep)
- Proper stable sort of vertices in the digraph module
- PkgDeps no longer 'see themselves' when fetching and upgrading after
  locking themselves
- Pkg Locks are added to pkg deps rather than source deps
- Updating test cases to support pkg mocking on top of src mocking

Apps that are no longer used are not automatically deleted, but we tell
users it can be done. This is safer while we're not sure of the
correctness of these messages.

Error messages are added for transient dependencies and dependencies not
found.

- Many apps is supported through and through
- Not mentioning any app upgrades all apps
- Locks are refreshed on disk and tested as such after an upgrade

todo:
- relock stuff
- default to all apps needing upgrade
- more tests?
- pkgs?

Only the most complex case is failing, where cross-dependencies would
need to be refetched as an update clears an app of its dependencies and
a different subtree should override it.

The problem with the current effort is handling of transitive dependency
upgrades and possible values.

Test that all the correct locks are set for an upgrade run.

Now to actually re-run the install deps and prove it works