Move path management out of rebar_utils manual code path function
handling (which we leave there for backwards compat), and centralize
them to allow easier coordination of paths between plugins and deps.

On top of path handling, do a check of loaded modules to only purge and
reload those that actually need it done in order to prevent all kinds of
weird interaction and accidental purge kills. It also allows the
possible cohabitation of both at once, with a "in case of conflict pick
X" as a policy

Changing path handling in providers also highlighted a bunch of bugs in
some tests and appears to fix some in other providers, specifically
around plugins.

* add compile type for dynamic project compilation

* new rebar_compiler abstraction for running multiple compilers

rebar_compiler is a new behaviour that a plugin can implement to
be called on any ues of the compile provider to compile source
files and keep track of their dependencies.

* fix check that modules in .app modules list are from src_dirs

* use project_type to find module for building projects

* allow plugins to add project builders and compilers

retired packages are now used the same as any other but
a warning will be printed when it is resolved.

prerelease versions are skipped unless explicitly given
as the version in the constraint or lock file.

When REBAR_CONFIG was set it would not effect the top level app's
configuration because app_discover was rereading the top level
rebar.config which ignored REBAR_CONFIG. Instead this patch has
it use the existing configuration from REBAR_CONFIG.

* update to hex_core for hex-v2 repo support (#1865)

* update to hex_core for hex-v2 repo support

This patch adds only single repo hex-v2 support through hex_core.
Packages no longer filtered out by buildtool metadata and the
package index is updated per-package instead of fetched as one
large ets dump.

* tell travis to also build hex_core branch

* support list of repos for hex packages (#1866)

* support list of repos for hex packages

repos are defined under the hex key in rebar configs. They can be
defined at the top level of a project or globally, but not in
profiles and the repos configured in dependencies are also ignored.

Searching for packages involves first checking for a match in the
local repo index cache, in the order repos are defined. If not found
each repo is checked through the hex api for any known versions of
the package and the first repo with a version that fits the constraint
is used.

* add {repos, replace, []} for overriding the global & default repos

* add hex auth handling for repos (#1874)

auth token are kept in a hex.config file that is modified by the
rebar3 hex plugin.

Repo names that have a : separating a parent and child are considered
organizations. The parent repo's auth will be included with the child.
So an organization named hexpm:rebar3_test will include any hexpm
auth tokens found in the rebar3_test organization's configuration.

* move packages to top level of of hexpm cache dir (#1876)

* move packages to top level of of hexpm cache dir

* append organization name to parent's repo_url when parsing repos

* only eval config scripts and apply overrides once per app (#1879)

* only eval config scripts and apply overrides once per app

* move new resource behaviour to rebar_resource_v2 and keep v1

* cleanup use of rebar_resource module and unused functions

* cleanup error messages and unused code

* when discovering apps support mix packages as unbuilt apps (#1882)

* use hex_core tarball unpacking support in pkg resource (#1883)

* use hex_core tarball unpacking support in pkg resource

* ignore etag if package doesn't exist and delete if checksum fails

* add back tests for bad package checksums

* improve bad registry checksum error message

- resolves #1645

This would cause crashes on linux and force people to have a src_dirs
config that is strictly matching what is on the file system rather than
acting as a specification of those that are valid.

To compare, if lib_dirs worked the same, then any repo that did not both
have apps/ and lib/ would crash, as the spec mentions both options as
valid.

- this is done by adding a HiPE dependency
- also in this: adding a test for directories, and fixing some indent

When adding the 'TEST' macro to the test profile, we mistakenly sourced
the erl_opts values from the base profile rather than the test profile
itself.

This means that in cases where the base profile set an option such as
'no_debug_info' and a profile overrode it with 'debug_info', the default
options would get injected within the test profile, and broke the
precedence rules, yielding incompatible values.

This patch fixes things by adding the macro to the values sourced from
the test profile itself, fixing the issue.

This reverts commit 4ad1db9733.

The way arguments are passed by the alias provider is not compatible
with all rebar providers/commands. Especially the release (relx)
provider does not like getting its arguments as a plain string. It
expects its arguments in a pre-parsed format as returned by
getopt:parse/2.

Other commands, e.g. eunit, seem to be fine with both ways of argument
passing. Therefore, this fix changes the alias provider argument passing
to the getopt format in general.

Although fairly irregular, the presence of a subdirectory in ebin/ while
running rebar3 escriptize would crash the run and generate a dump.

Since ebin subdirectories are generally not supported (adding a path for
an application only adds ebin/ and no subdirectories to the VM's path
set), we just silently ignore the directory altogether.

Fixes #1693

- Uses the code at https://github.com/tsloughter/rebar_alias and brings
  it within rebar3
- adds safety checks to prevent redefining built-in commands or obvious
  circular dependencies between commands (indirect circular deps are
  still possible)
- adds tests
- adds a systest to ensure no clash with the existing plugin

Adds an option (-m, --min_coverage, or {cover_opts, {min_coverage,X}})
to the 'cover' command, where the value is an integer between 0 and 100.

If the total coverage during the analysis is below the value received,
the command will fail with output like:

    ===> Requiring 64% coverage to pass. Only 62% obtained

If the rate is correct, the command silently passes as it currently
does.

This feature allows to enforce code coverage standards in a project if
desired.

Current rebar3 uses debug_info rules where debug_info is added by
default, and no_debug_info prevents the default from being added, and
removes any explicit debug_info, if any. The problem is that if
'no_debug_info' is anywhere in the config for a run, it cannot be
removed even with other profiles. additionally, no_debug_info ignores
special tuples like {debug_info, {Mod, Data}} and {debug_info_key, Key},
which can be used to add debug info and encrypt it (in lieu of plain
debug_info) respectively.

This patch makes it so that the following rules are in place:

- the last option seen takes priority, allowing profile overrides by
  the ordering rules the compiler expects
- the overriden options shall be explicitly deleted to avoid confusing
  the compiler
- any option related to debug info seen last cancels any no_debug_info
  that preceded it
- any no_debug_info option seen last cancels all of the other
  debug_info options
- if debug_info is seen last, it cancels out {debug_info_key, Key}
- if {debug_info_key, Key} is seen last, it cancels out debug_info
- All other options are left untouched in that context (defines can
  still be expanded and so on)

This should allow proper profile rules to be followed. Note that erl_opt
profile merging puts precedence on the *last* element of a list, to
match the compiler.

This replaces all deprecated function usage by alternative ones based on
a version switch enacted at compile time, preventing all warnings.

This will likely introduce some possible runtime errors in using a
Rebar3 compiled on OTP-20 or OTP-21 back in versions 19 and earlier, but
we can't really work around that.

A bunch of dependencies have been updated to support OTP-21 without
warnings as well.

The compiling of OTP applications is done by first topographically
sorting them according to their dependencies, deps-first. This allows
all compilation to take place in order. In the current code, the same
logic extends to top-level applications in an umbrella project.

Unfortunately, there are cases where this is not going to be true: when
an application has extra_src_dirs entries (or additional directories or
files) to conditionally compile under some profiles, it may start
depending on another top-level application dedicated to that profile for
include files.

However, such an app will never make it to production and neither will
the compilation artifacts that create the dependency. Under that
scenario, current rebar3 is unusable.

This patch makes it so that the compilation provider instead changes the
logic for top-level apps: rather than copying their directories one by
one and compiling them in order, it:

1. copies all top-level apps to the build directory so the files are in
   their proper locations
2. adds the top-level apps to the path (after the global hooks have run,
   so the existing scope and env has not changed)
3. runs the compilation as usual.

Fixes #1651

Getting real tired of that nondeterministic set of runs on OSX CI

The previous patch at #7c959cc fixed the usage of duplicate values
for directories through relative paths, but mistakenly went overboard
and dropped the `./` path, which is still fairly common. Similarly for
`../".

The code is modified to special-case such values and keep the code
working.

When fetching src_dir values, some relative paths can be inserted. When
deduplicating the paths on the fetch, this fact means that logically
duplicate (but literally different) directories can be returned at once.

By normalizing the names, duplication bugs can be resolved.

Specifically, this impacts profiles. It appears that relx as a whole
requires its configuration to be merged in one tuple order (New takes
precedence over Old), whereas the overlays require the opposite (Old
takes precedence over New) since the operation order on disk is
important to work well.

This patch reorders overlay values such that the overlay of a profile
takes place *after* the basic overlay, ensuring that the profile actions
take place after the basic ones; this allows profiles to properly
overwrite files as expected (see #1609)

This is done while adequately maintaining the order of operations that
were required as part of #1563

Overlay vars of profiles are also checked to be working fine, along with
a test.

This fixes #1247 and #1609

When a config file exists at the root of a project, defines a given
configuration value for a given profile, and that a sub-application
(umbrella app) also has the same profile defined with the same key (but
different values), the configuration values of the sub-application's
profile would get silently dropped.

The problem being that when the function to merge profiles is applied
recursively, it is applied to each profile (so it will merge on the keys
test, prod, etc.) rather than to each of the values of each profile.

This patch reworks the profile merging so that the current behaviour is
respected overall (a profile cannot be cancelled by a subdep's
non-existant profile since its value should have been ignored), but
ensures that sub-deps' profiles are otherwise applied recursively with
the proper rules:

- dependencies favor prior values
- plugins favor new values
- erl_first_files combine the lists
- relx uses the tuple merge algorithm
- erl_opts has its own custom merge as well
- otherwise the new value takes precedence

A test has also been added.

There is a risk of breakage in some applications that may have relied on
the buggy behaviour to work, though at this time we are aware of none of
them.

This is done through 3 main change groups:

- replacing `~s` by `~ts` in format strings, so that strings that
  contain unicode are properly printed rather than crashing
- adding the `unicode` argument to all function of the `re` module to
  ensure transformations on strings containing unicode data are valid
  instead of crashing (see issue #1302)
- replacing `ec_cnv:to_binary/1` and `ec_cnv:to_list/1` with matching
  functions in `rebar_utils`.

The last point has been done, rather than modifying and updating erlware
commons, because binary and list conversions can be a contentious
subject. For example, if what is being handled is actually bytes from a
given binary stream, then forcing a byte-oriented interpretation of the
data can corrupt it. As such, it does not appear safe to modify erlware
commons' conversion functions since it may not be safe for all its
users.

Instead, rebar3 reimplements a subset of them (only converting
atoms and chardata, ignoring numbers) with the explicit purpose of
handling unicode string data.

Tests were left as unchanged as possible. This may impact the ability to
run rebar3's own suites in a unicode path, but respects a principle of
least change for such a large patch.

The use case has been described in issue #1478 where a local application
can exist while being declared as a dependency as well. This allows, for
example, to work on a release where all applications may require to be
published independently, or to provide some form of 'vendoring' with a
local app.

The fix is done by decoupling the dependency source resolution form the
dependency parsing. The reason for this being that the discovery phase
needs to parse apps for their top-level deps, and dep installation needs
to resolve the packages with accuracy. In the current implementation,
both code paths call to the same function.

This patch splits up the precise discovery and makes it happen *only*
when installing dependencies, and only if a top-level app does not
already define the application needing resolving.

One weakness of this fix is that it necessarily breaks cycle detection
in dependencies that involve a root application depending on itself
since its own version as a dep will not be expanded. There appears to be
no possible way to prevent this, but should be rare enough to be worth
the tradeoff for the common case.

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.