Rather than the caller having to think of what to purge or not, use
erlang:check_process_code/2 to detect if the caller (rebar3) may die
because of the operation.

If so, do a soft purge with a conditional delete instead of a hard purge
with a mandatory delete.

Prevents the killing of a plugin with itself

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.

When a global plugin is used both locally and within the project, there
are cases when the rebar3 program will hard crash (killed in do_boot).
This has been traced to plugin-handling in compilation, where the same
code path may be purged twice in a row without further reloading for the
compile operation.

This of course yields the result where the code handling on the VM kills
all processes holding references to the module in memory, in this case
the rebar3 process itself.

By deduplicating the paths first, we ensure at most one purge before
reloading plugins and paths, and this prevents a hard crash.

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.

rebar_file_utils:cp_r uses rebar_utils:escape_chars to ensure that the file names are safe to use, but it doesn't escape double and single quotes. If the file name includes those characters, they disappear when the shell processes them and we get "file not found" errors.

The main culprit here is eunit, that creates reports whose names are `TEST-file_"myfile.app".xml`, and I wish it didn't but I think escape_chars should still do its job all the way.

Includes improvments and function documentation for all modules (in
alphabetical order) up to rebar_core, and may have included more in
other modules as I saw fit to dig and understand more of the internals.

- restore path after loading applications,
- helpful comments.

- The configured stuff in rebar3 takes precedence over the ENV
- The env is then chosen

this is slower than the compile time check but i guess packaging rebars with
repos is still a thing and i think only the eunit and ct providers call it
anyways

Full rewrite, code should be understandable now.

- proper segregation of comparison between tuple terms and non-tuple
  terms. Guards weren't specific enough and that meant the wrong clauses
  of guards would be triggered
- proper deduplication of entries in the list. An additional N passes
  are required (we co-opt the reverse step to be more efficient) because
  while the original lists:umerge easily removes dupes, this is
  requiring more logic here since `[a,{a,b},{a,b,c},a,{a,b,c}]` is a
  possible interleaving and we'd want `[a,{a,b},{a,b,c}]` -- comparison
  of direct neighbours isn't enough.

at the cost of some SASL warnings this prevents rebar3 from terminating
processes when reloading their code before running tests

prevents code reloading by temporary marking of rebar3's ebin dir
as sticky during code refresh

* modify compiler interface to work on either application objects or
  directories containing source files
* compile all sources in `src_dirs` to the application `ebin` dir and
  all sources in `extra_src_dirs` to a directory mirroring it's
  position in the app's `_build` directory. for example, `apps/foo/more`
  would compile to `_build/default/lib/foo/more`
  for `extra_src_dirs` in the root of a project with multiple
  applications (so orphan directories that don't "belong" to an
  application) compile to `_build/default/extras/more`
* copy directories specified in `extra_src_dirs` into the `_build`
  directory so tools like `ct` and `xref` that expect source to be
  in a particular location still work
* clean compiled artifacts from all `extra_src_dirs`
* alter `eunit`, `ct` and `cover` to work with the new directory
  structure
* billions of new tests

In the spirit of Original Rebar's "require_min_otp_vsn", this adds
rebar_utils:check_min_otp_version/1 (taking a string containing the
minimum version) and rebar_utils:check_blacklisted_otp_versions/1
(taking a list of regular expression strings), as well as tests in
rebar_utils_SUITE. They're currently only called by the tests-
how/where to best place calls to them from non-test code needs to be
determined (at which point two corresponding rebar.config keys can be
supported). For example, the version probably shouldn't be enforced when
just running "rebar3 help".

Basic escaping is done only. Fancy hex sequences are not covered, but
this should otherwise take care of the most common issues.

Fixes #497