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.

The list of applications in the relx config section could contain
tuples. The tuple will either contain a version constraint for the app,
the start type of the app or both.

This fix silently expands `{shell_apps, [Apps]}` to support the same
format.

The current code could not cope with missing dependencies, as they would
prevent the rebar3 app from loading or properly building its config,
which prevented the log state from being carried along with default
values. This in turn would turn in an escript-level error that
obfuscated the true source of failure.

This patch bypasses the whole state setup and logging macros and logs an
error message manually when a dependency such as crypto or SSL is
missing from the Erlang install.

to `rebar_erlc_compiler`

In the scenario we that we have selected a commit
that is between two tags, we should base the
version on the most recent tag we can see in the
revision history, but we should not treat this as
the tag version.

`git describe --tags --abbrev=0` finds the most
recent tag visible in the revision history from
the current HEAD. Return this as the version
string and undefined as the tag to trigger ref
counting.

In the scenario that someone had cloned an entire
repository and then checked out an older version
tag, the semantic versioning would detect the
newest tag, not the checked out tag. Look for
the HEAD string prior to tag: to indicate the
currently selected tag.

Version #'s with patch info like "1.1.1-x" would cause an error. Now
tokenize the version string with "." AND "-".

In the scenario we that we have selected a commit
that is between two tags, we should base the
version on the most recent tag we can see in the
revision history, but we should not treat this as
the tag version.

`git describe --tags` finds the most recent tag
visible in the revision history from the current
HEAD. Return this as the version string and
undefined as the tag to trigger ref counting.

In the scenario that someone had cloned an entire
repository and then checked out an older version
tag, the semantic versioning would detect the
newest tag, not the checked out tag. Look for
the HEAD string prior to tag: to indicate the
currently selected tag.

Not all repositories use a v-prefix for version
tags. All tags should be considered valid
versions.

`reduce_path/1` -> `canonical_path/1`
`relative_path/2` -> `path_from_ancestor/2`

add tests