When a given behaviour module does not exist, rebar3 brutally crashes.
This patch makes it so instead, there is a warning output menitoning the
missing behaviour, and this one is omitted from the unused function
calls check. This means that unused calls will instead be shown for the
module implementing a non-existing behaviour, as if no behaviour were
declared in the first place.

If xref analysis is being run by a dependency during its compilation
phase, the xref provider will try to add that deps' parents to the check
job while the ebin/ directories for them do not exist. This causes a
crash.

This patch makes it so directories are only added if they are existing,
preventing failure on any compile hook for dependencies and allowing
successful compilation as a best effort.

This mostly moves a lists:reverse/1 which ensures that profile overlays
are run first but keeps the order of overlays otherwise.

Prevents showing false upgrade messages when upgrading in a non-default
profile. Also shows an info message explaining default deps don't get
updated in a non-default upgrade.

This fixes the output of end_per_testcase crash notifications when the
test passes.

This also detect an issue of the kind with rebar_pkg_SUITE which is now
fixed.

The option {spec,Specs} is allowed in ct_opts, but
rebar_prv_common_test:test_dirs did not take into account that Specs
could also be a string only, i.e. not a list of strings.

The finding of the file was done based on an assumed 'src' path which
may not be correct. This patch instead replaces the value with a lookup
in configured paths and returns the first that matches to an existing
file.

First find the rebar.config file, and if any data is found, check for
src_dirs config. If nothing is there or no app is found, default to src/

This lets people who use custom directories layout without leaving the
.app.src in src/ to still see their app build.

Adds a new option `{cover_excl_apps, Apps}` to exclude apps from coverage
analysis by name.

on 19.x forward the compiler should now take into consideration the value
of the environment variable `ERL_COMPILER_OPTIONS` when deciding whether
or not to recompile a module

Instead of a hard crash, display an error message indicating which app
failed.

We can't report the exact failure; only EDoc does it to stdout itself
and we can't capture it.

Pre/Post hooks are run properly despite the failure, as per escript and
compile providers.

to be roundtripped again to windows.

Requires changing a bunch of arguments for xerocopy since it
does not allow to rename while copying.

Lots of tests added

Parse given test specs and add all spec- and suite directories as
extra_src_dirs in order to ensure that all these directories are
copied to the _build area and the suites are compiled.

Specs located in the project- or app root are explicitly copied to the
_build area in order to avoid recursive copying of the complete
directory tree.

This is a bugfix. It makes sure that the given path to a testspec is
translated so common_test will pick the spec from the _build
directory, and not from the source tree.

This is necessary in order to automatically get the testspec included
as an artifact (i.e. copied to the _build dir) in the case when it is
stored in another directory than 'test'.

Bug: option 'spec' is not specifically handled when merging options
from the command line with options from rebar.config. Due to this, if
the config specifies a 'spec', then this will take precedence over any
'dir' and/or 'suite' on the command line.

This commit takes special care of all options that can be used to
select tests - meaning that if any of the options 'spec', 'dir',
'suite', 'group' or 'case' are specified on the command line, then all
'spec', 'dir', 'suite', 'group' and 'case' options in rebar.config
will be ignored.

The option {recursive,boolean()} can now be set pr directory in
'src_dirs' and 'extra_src_dirs', and on top level in the new
'erlc_compiler' option. Example config:

{erlc_compiler,[{recursive,false}]}.
{src_dirs,[{"src",[{recursive,true}]}]}.

This will cause recursive compilation within the "src" directory, but
not in any other directoires.

* exclude_apps - never use applications for PLT/analysis
* base_plt_mods - add modules to base PLT (overrules exclude_apps)
* plt_extra_mods - add modules to PLT (overrules exclude_apps)
* exclude_mods - never use modules for PLT/analysis (overrules all)

`rebar3 ct --spec foo.spec,bar.spec,baz.spec` now works

also added support for the `join_specs` flag on the command line

checks on hd(...) and so on could not handle empty lists

This adds tracking of package hash in the in-memory index rather than
the current `undefined' values.

According to the test added, this is not necessary for transitive
package dep hash chcking, but does result in a more complete index search
result when doing app lookups, and could yield some optimizations on
hash checks by checking from the index structure before fetching a package.

When an include file is set in a private path (i.e. src/), the rebar3
compiler would not add them to the {i, Path} params -- only include/ and
the project root were being added.

This meant that when some extra source directories were added to the
compile job, such as test/ when running under the test profile, the
private include paths could not be shared with the test module.

This patch fixes the issues (and adds tests) for such a specific case by
adding all the configured include paths to the {i, Path} erl_opts
arguments, yielding successful compile runs.

Aliasing only had a bit of ad-hoc support in rebar3, and various issues
have encountered problems related to the package names not mapping
properly with the application name. One such issue is
https://github.com/erlang/rebar3/issues/1290

The problem has been hard to find because it only impacts transitive
dependencies (not top-level ones) of other packages. The root cause for
this is that the application name was not being tracked by rebar3's internal
index, only the package name and its version were.

When a given application was a package app, the data for the application
name would be reconstructed from the lock file, but only if it were a
top-level app or a dependency of a source application where parsing the
lock file is necessary to know what comes next.

When a transitive dependency of a package dependency was fetched, we
instead read its dependencies directly from the in-memory package index
within rebar3. This caused us to only read the package name and version,
and lost all information regarding application name. This worked fine
for most cases since for the vast majority of packages, the package name
matches the app name, but failed for all aliases, which would then be
moved to directories that wouldn't match the app name.

This in turn broke some aspects of code analysis (in Dialyzer), or other
functionality relying on static paths, such as including .hrl files from
dependencies.

This patch reformats the internal storage format of dependencies to
align with the internal one used by rebar3, so that the app name can be
carried along with the package name and its version.

The fix can only work once `rebar3 update` is called so the index is
rebuilt internally, and will the file cached on disk will be
incompatible with older rebar3 versions.

Currently, the following is not covered:

 - Tests
 - Including the package hashes of dependencies so they may match what
   is in a lock file -- they're being `undefined` instead, which may
   break some lookups. The previous format did not lend itself to hashing
   in the same way, and it is possible transitive deps were not being
   tracked properly, or worked by respecting the current package hierarchy.
   This will require further analysis

For now this commit can allow reviewing and discussion.