Handle control sequences in formatted errors

Formatted errors can accidentally contain substrings which are control
sequences for io:format/2. This is a naive attempt to handle such cases.

One example is running xref on the following module
(assuming module m does not exist)

```
-module(handle_error).

-export([f/0]).

f() -> m:'bobby~stables'().
```

```
$ rebar3 xref
===> Verifying dependencies...
===> Compiling myapp
===> Running cross reference analysis...
escript: exception error: bad argument
  in function  io:format/3
     called as io:format(<0.23.0>,
                         "\e[0;31m===> \e[1mWarning: handle_error:f/0 is unused export (Xref)\nWarning: handle_error:f/0 calls undefined function m:bobby~stables/0 (Xref)\n\n\e[0m\e[0m",
                         [])
  in call from rebar3:handle_error/1 (/Users/gomoripeti/git/rebar3/_build/default/lib/rebar/src/rebar3.erl, line 279)
```

When the operation for an unlock takes place in the config of a umbrella
application, the `unlock' provider does not see the dependency in the
`deps' value of the config (since it only includes the deps at the root
of the project) and ignores these.

Don't die when source deps with [raw] are used

Debug log update

This adds support for their format both on the first read and when
looking for modifications to dependencies.

- also making sure unlocking works fine

Tests have broken as locks were expanded and auto-filled newer versions
of lockfiles. This fixes them back.

- the internal representation for package locks moves from `{Name, {pkg,
  PkgName, Vsn}, Lvl}` to `{Name, {pkg, PkgName, Vsn, Hash}, Lvl}`
- the internal representation for packages moves from `{pkg, PkgName,
  Vsn}` to `{pkg, PkgName, Vsn, Hash}`
- the hash can be `undefined`, meaning no check will be done
- no checking is done yet.

adjust `data_dir_correct` test in ct suite

don't bother checking the profile in the path to the data dir

filter available package versions individually by buildtools

deploy escript to travis releases instead of s3

Fix path command to consider {deps_dir, "deps"} in rebar.config

#1185 fix windows git working directory

fix issue #1185 git working directory issues due to command line options in Windows

don't needlessly update the code path twice if no hooks to run

don't generated coverage for `extra_src_dirs`

closes #1057 and #1179

fix otp-19 bootstrap compiling

upgrade erlware_commons for OTP-19 fix

Fix shell node startup

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.

Add support for xref_ignores

Allows overwrite default cache dir using REBAR_CACHE_DIR

Fixes logging from remote shells in rebar3 shell

Add a provider hook for edoc

Change to new hex.pm repo URL

upgrade relx to 3.19.0