Should fix #360

Allows to remove entries from the lock file, or the lock file as a
whole.

When fetching dependencies for the first time using a profile (`rebar3
as prod release` or `rebar3 ct`), the dependencies get fetched into the
non-default profile. This has two consequences:

- the files get re-downloaded on follow-up runs
- the lock file includes incomplete or too many deps in its list

This patch forces dependencies in the default profile to be stored in
_build/default/lib even when running under other profiles, then symlinks
them to the correct one.

This makes it so common dependencies in 'default' be downloaded there
and avoids re-downloading them. Should also fix the lock issues.

alongside their source (ie, if `some_tests` is a directory that
contains test suites beams resulting from compiling them will be
placed in `some_tests` in the appropriate `_build` directory

to the appropriate `_build` dir

matching directory paths

run subsets of test suites

test utils and add better eunit tests

Add test case to exercise the eunit provider using the test profile

Add one test case to verify the dev_mode option for a release and
another to verify overriding the dev_mode option in a profile for a
release. Verification of proper dev_mode functioning is done in the
rebar_test_utils:check_results/2 function by checking if all the
directories in the release lib dir are symlinks or not and comparing
that result to the dev_mode expectation passed as input to
the check_results function.

Rather than using the stdlib lists:umerge, we expand it to allow fuzzy
matching on tuples vs. vals (`key` vs. `{key,val}`) with an overriden
sort order so that two tuples or values comparing equal get a priority
on the newest profile.

This is a partial fix for #287 -- this current patch should be followed
by a relx update to take options in order (as if they were a proplist)
to complete it.

The option {deps_error_on_conflict, true} will make it so conflicts in
deps being fetched interrupts the operation rather than just display a
warning.

Defaults to `false'.

get correct compile paths included in module info

This adds some more convolution to command parsing, unfortunately, but
makes some cases clearer (`rebar3 as as as as` is no longer valid). It
unfortunately disallows using $REBAR_PROFILE along with `as` in a rebar
command.

fixes #238

profiles are failing to be applied

relevant to #224 and #233

fixes #216 and #220

to `as` used to generate them

pre-purging before checking to facilitate long do chains

`rebar.config` or via the `-c\--cover` flag given to the appropriate
task) from the `eunit` and `ct` tasks and add a `cover` task to
write coverage analysis to disk

The session was unfruitful, but I guess the tests were not necessarily