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.

Has no ill effect as tested on Win10

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.

Rather than trying one method and then the other, allow the caller to
specify the encoding of the expected file. All other schemes are risky
and won't work well.

Rollback the function's default interface to the binary format in case
any plugin used it for non-unicode content, preserving backwards compat.

The code for symlink handling failed whenever a win32 platform with no
symlink capability would be detected. This patch is provided by
William H from the support ticket at
http://www.rebar3.org/v3/discuss/598225c90365bb00144bc07f, which
adds detection of failures in non-NTFS scenarios on Win32, and then
copies files instead of bailing out.

The end result should be appropriate support for such a platform.

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.

and clean up a bit

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

Lots of tests added

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.

In some cases, mv will throw a warning, while still moving the files
correctly and returning a 0 return code:

"mv: can't preserve ownership of ... Permission denied".

By default rebar3 displays compiler sources as absolute paths in their
original location, which is under the build dir.

This change introduces an option 'compiler_source_format' to format
sources in two alternative ways:

    relative
    absolute

When either 'relative' or 'absolute' are specified, the file is
resolved to its original location when it is a link. When 'relative'
is specified, the path is displayed relative to the current working
directory. When 'absolute' is specified, the path is absolute.

The default value is 'unchaged' which leaves the compiler source
unchanged.

This is arguably too flexible as I suspect most people would opt for
'relative' all the time - it's the most compact representation of the
file and is sufficient to find the source given cwd. The change
however is meant to introduce the change gradually, preserving
existing behavior and giving users a choice for formats.

In time perhaps the default can be changed to 'relative' - but still
allowing users to revert to the other two options ('absolutel' and
'unchanged') as needed.

- robocopying a directory into another directory recursively expects the
  directory name to be properly mapped onto the destination, otherwise
  all the files are copied into the given path. This patches things so
  a directory-to-directory robocopy works as expected in a linux mindset
  so tests pass
- the test for canonical paths didn't expect a windows environment at
  all; the test (and library) is modified to be consistent in that
  environment: always with a native format and with proper support of
  drive letters.

`reduce_path/1` -> `canonical_path/1`
`relative_path/2` -> `path_from_ancestor/2`

add tests

This patch forces write_file_if_contents_differ/2 to use raw bytes as
when writing files. This fixes an issue where UTF-8 characters are
processed and written back as ISO-8859-1 into the file, which makes it
impossible to use UTF-8 characters in .app.src files.

Linking message will only be printed the first time the link or copy
actually happens.

Note:

rebar_file_utils:symlink_or_copy will now return 'exists'
instead of ok, if it did nothing because the link exists.

Nothing was checking the return value yet, so seemed reasonable.

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

Fixes #497

(in `rebar_file_utils`)

While at it, improve the error message printed by rebar_utils:sh/2.

'Erlang' projects that do not contain any erlang files (Joxa, LFE,
Elixir, etc) break the eunit task. It attempts to copy an empty list
of source files to the .eunit directory. This change makes copying an
empty list a simple no-op.