End result should allow to look like this:

    $ head -n 3 rebar3
    #!/usr/bin/env escript
    %% Rebar3 3.14.0-rc1
    %%! +sbtu +A1

This will allow tools like mix to read the top of the file to know the
version being used in the current path (when using features that aren't
forwards-compatible) without having to invoke the tool itself.

The version (full dynamic one) is also added to the local install:

    $ head -n 2 /home/ferd/.cache/rebar3/bin/rebar3
    #!/usr/bin/env sh
    ## Rebar3 3.14.0-rc1+build.4599.ref6b0f90d

The `##` comments are used to keep a fixed width over the other form.

To be backported to 3.13.2 as well.

This commit switches the relx dependency to branch 4.0.0. It is the
first iteration of integration with relx 4.0 which adds many changes
to how relx works and how the two integrate.

rebar_relx module now creates a relx state from the relx configuration
and pass it along with all the OTP applications rebar3 knows about
which may be used in the release. This allows relx to not have
to duplicate the effort of application discovery like before.

Since this is intended to be released only when OTP-23 is released
the testing of OTP-18 has been removed.

- topsort of an app does a full analysis of all apps to come up with
  their app-level DAG
- each extra_src_dir has its own analysis run
- each extra_src_dir run is simulated as being an app
- we therefore end up doing a lot of useless analysis for single app
  runs

This patch notes runs with 1 or 0 apps and skips doing the topsort
analysis on them, which speeds things up further.

Would close erlang#2202. In case of no apps found when calling
`rebar_state:project_apps(State)` rebar3 now throws an error with
a warning.

Closes #2108. Changes the path to be printed to a relative path
to the current directory.

Also removes the `exports_not_used` warning from the default ones,
as Tristan suggested.

Also fixes artifacts left on filesystem, and produces less
filelib:last_modified() checks.

now all sources have at least one edge with 'artifact' label,
let's ignore it when choosing whether to compile in parallel
or sequentially

The propagation was confusing source files and artifacts; the artifact
ordering was flipped, and the tagging non-mandatory (aside from as
edges), which made things hard to identify when plugins for compilers
are used.

Now it should work in Erlang/OTP versions earlier than 20 and
update the symlink in case of one already existing (so that `last`
always points to the last run).

This patch enables two features:
 * in rebar.config, {diazlyer, [{plt_apps, all_apps}]} makes rebar3 to
   add all project files into PLT for subsequent analysis
 * rebar3 ct --app=myapp allows single application success typing

This allows workflow suitable for large codebases:
 * "rebar3 ct dialyzer --succ-typings=false" to build PLT with all apps
 * "rebar3 ct dialyzer --app=myapp" to perform success typing of myapp

Implements #1734. In case of not being able to create the
symlink rebar3 warns through `?DEBUG`.

As suggested in #2223, `make_absolute_path/2` and `make_normalized_path/2`
should, instead of being exported in `rebar_dir`, be moved to
`rebar_file_utils` and renamed (decided to simply remove the `make`
from their names since in that module there is already a path related
function called `canonical_path`).

This allows to do quicker re-compile option validation by not requiring
to access the disk and check all candidate erlang files for option
changes. This also opens up the way to compilers that produce more than
one artifact per file.

rebar3 uses following git invocation when it needs to generate
vsn to put into app.src:
git -c color.ui=false log --oneline --no-walk --tags --decorate
It may return something like some_repo/some_project/12345678,
with some characters preceding actual hash. This leads to some
unusual version written into application resource file, e.g.
{vsn, "some_repo/some_project/123456678"}.
This does not work well with semantic versioning, and also
produces unexpected OTP application names and folder names,
e.g.
myapp-some_repo/some_project/12345678

THat was code written on a bus and rarely executed, but still the
function called didn't exist for real.

Reduces dependency verification time for large codebases.

Fixes https://github.com/erlang/rebar3/issues/2242
Filters out dead processes that can't return process info.

- Normalize path behaviour to always be "/" across versions
- Normalize port visibility behaviour to match input string when
  appending
- restore rebar_utils function to avoid breaking random plugins that
  peek into our libs for their stuff
- Support URIOpts equivalent and protocol-based overrides; the behaviour
  there is not necessarily consistent across versions in terms of what
  ports are returned (http_uri always returned a port but uri_string
  only returns it if explicitly specified -- we choose the latter
  behaviour on newer releases), but the calls work to ensure URI parsing
  consistently works across versions

The latter judgement call is a bit of an odd one; for consistency we
could always mandate ports, but this would come at a performance penalty
when appending URL paths (i.e. when fetching packages).

The reason for this is that we standardize on the new uri_string
behaviour for path appending (if the port wasn't specified, we don't add
it), and with the http_uri rules, we need to do a kind of parsing round
that checks if the port was included or not to make it equivalent. This
is costly, and _not_ returning the port when it isn't specified lets us
do this transparently.

This allows to maintain backwards compat in older append functions, and
nobody aside from us currently uses the new rebar_uri module so we can
decide to introduce this potential inconsistency if we wish to.

(cherry picked from commit fa577bc46e)

Attempts to bridge http_uri (deprecated in OTP 23)
and uri_string (available as of OTP 21+).

(cherry picked from commit 7057cbe281)

Currently, we just write to ebin/ in the current working directory; this
implies that the source _should_ always be in the same subpath as the
ebin/ directory.

In the cases of utils like Mix, which store downloaded dependencies in
deps/ and artifacts in _build/, this may force more rebuild or less
caching that would be ideal.

This PR adds --outdir / -o as options to the bare compiler, which lets
the user specify another path, with a default kept to $CWD.

- Can't deal with := in map type declarations
- maps:update_with didn't exist back then so we reinvent it for the few
  months until we deprecate OTP 18

This moves the old DAG stuff out from the main code paths and
substitutes it with the new epp-based DAG work.

Also fixes previous work for integration tests:

- consider ptrans from erl_opts in app ordering
- display proper app compilation info messages due to reordering

While leaving the old one in place, prep the ground for new analysis
phases for the DAG work. The new DAG functions are added, but not hooked
in yet.

Fixes to the EPP handling have also been added due to issues in
resolving include_lib information

This commit is a transition point that makes some assumptions about new
callbacks for the compiler modules, which will likely not hold when it
comes to making epp be able to read and handle multiple applications at
once (so it can resolve parse transforms and behaviours across OTP
apps).

As such, a follow-up commit is going to be completing that one and
changing its API in incompatible ways; if you find this commit during a
bisect, it's probably not a good one in which to run a bisection.

This reverts commit 025a96b143.

Solves #2071, IPV6 support for proxy, by trying to resolve proxy
host name without specific IP address family. If it fails, it
attempts a different IP family, and in case that succeeds, it
sets up HTTP client profile to use IP family that worked.

This enables relative paths for checkouts_dir configuration variable.

It is quite normal to have git 2.17.1 on MacOS X.

The code was written at the time only one lockfile version was being
explicitly tagged (1.1.0), and all the other older ones were untagged.
In introducing the 1.2.0 format for external hashes, the current version
check still took place, but no provisions were made to explicitly check
between older or newer versions. As such, rebar3 would warn (prompting
people to upgrade) every time a lockfile on the 1.1.0 version (which is
likely over 99% of those in the wild as of today) would be encountered,
we'd prompt people to upgrade.

This patch introduces a constant for the list of supported tagged
versions for config/lock files, which allows to drop warnings when
rebar3 can transparently upgrade the lock file for the user.

It pre-supposes a potential "unsupported lock file" error could be added
in the future if a config format is not newer but in fact explicitly
deprecated. This isn't implemented but the current logic works towards
making that support possible.

- Vendor in hex_core at v0.6.8
 - Rename checksum to inner_checksum and deprecate in favor of new outer_checksum key/val
 - Change warn_vsn_once/0 to warn_vsn_once/1 so we can give a proper error message and
   take appropriate action.
 - Update rebar.lock to 1.2.0 format with continued support third-party
   that still may make use of inner checksum via continued persistence of
   inner checksums.
 - Changed app info tuple (package representation) to support inner and
   outer hashes for backwards compat support (see above)

This is another tricky commit towards replacing the current module
analysis with EPP. The compiler DAG is now being shared across multiple
applications being compiled, rather than a per-application basis, which
promises to allow better ordering, parallelism, and more thorough
invalidation of runtime dependencies when they are modified.

This however required changes:
- The compiler DAG is no longer private to `rebar_compiler`, and has
  been extracted to the `rebar_compiler_dag` module
- The compiler DAG is now started by the `rebar_prv_compile` module,
  which oversees the calls to `rebar_compiler` for each OTP application
- The compiler DAG has been refactored to use a "dirty flag" to know if
  it was modified, rather than just tracking modifications in a
  functional manner, since the scope change (going multi-app) makes it
  impossible to cleanly use the functional approach without much larger
  changes
- The DAG used to be cached within each OTP application. This is no
  longer possible since it is shared. Instead the DAG is stored in the
  state's deps_dir, which allows to cleanly split caches between regular
  apps for the user's project and plugins
- The DAG supported a "label" mode that was used to store distinct DAGs
  for extra_src_dir runs and regular modules; this label is now used
  (and extended to `rebar_prv_compile` internals) to distinguish between
  "compile runs", such as "project_apps", or just "apps" (deps). The
  label is optional (i.e. not used by plugins which have no such need)
- The extra_src_dirs for each app is now compiled using the main app's
  DAG, but the run takes place later in the compilation process. This
  may need changing to detect and prevent dependencies from src_dirs
  into extra_src_dirs, but this should not technically be a problem for
  runtime anyway.
- Reworked the support for extra_src_dirs that are at the root of an
  umbrella project (and therefore do not belong to any single app) to
  use the new structure, also as part of the project_apps DAG.

All tests keep passing, and this puts us in a better place to use EPP
with cross-app support in the near-future.