The previous iteration of the patch worked somewhat by accident. After
digging in and figuring out why the two dep sources are the way they
are, the patch is now properly working with a well-documented
explanatiion inline.

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.

Instead fetching and resolving src deps (which could depend on pkg deps)
and then pkg deps this patch combines the two into a single set of
iterations by level. The only difference between src and pkg deps in this
new install_deps is how their deps list is found -- from the config or
lock file for src deps and from the neighbors of the vertex for pkg.

- Crashes in providers lib when no providers in a namespace are bare
- Making sure bareness matches semantics; i.e. a bare provider is
  visible, a non-bare provider is hidden.

they would always be left unfound otherwise.

Also expose it in rebar_api

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