upgrade relx. it wasn't creating nodetool

make short name the default in vmargs

fix dialyzer warnings

only upgrade children and transitive children of dep being upgraded

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.

Shell handles all possible relx app formats

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.

Properly warn on missing rebar3 deps

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.

fix canonical path tests on windows

add an export to allow specifing arbitrary extra erl files to be compiled

test for ensuring `data_dir` is set correctly in ct configs

extract `retarget_path/2', `relative_path/2' and `reduce_path/1' and add tests

add DEBUG statement of the command sequence that'll be run

Bump relx to 3.7.0

handle newly added deps to config even when lock is empty

Fix consult_and_eval/2 to behave like consult

Write original messages not fancy ones to disk

Colorized dialyzer output

Git versioning 2

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.