Refactor env path handling and fix some bugs related to it

[ferd]

This updates and replaces how most of the path handling in rebar3 is being done. Instead of adding paths here and there mostly at random, this attempts to take a more systematic approach of tracking currently-used modules and replacing them explicitly, while caring for plugins or deps to be in proper order.

Implements the fixes proposed at #1899

Also fixes a path bug in the compiler.

[ferd]

Cleaned up commits in a more logical unit. Probably ready to merge after reviews and confirmation it does not break things (and possibly fixes them!) for @tothlac and @eproxus since you both are probably our biggest plugin users.

I tried it on my own rebar3 proper and found no problems.

Probably worth taking some time to do profiling as well.

[ferd]

A quick check on run times for the test suite reveals that this patch set is almost 40% slower than what we had before.

There's obviously a need to rework the stuff taking place in this PR so that it is faster, or gets similar paths set at a lower runtime cost.

[ferd]

I found the source of the performance regression and fixed it:

• Only set paths that need to be put as a priority
• Clean up paths before leaving API mode

The first point accounted for some performance cost, but nothing major.
The second point explains the 40% overhead in test runs: since tests call
a lot with a bunch of fake apps, and that the new mechanism for path handling
by default does not remove paths, it just orders them, we would end
up in a situation where as the tests ran, more and more fake paths would
get added to the VM.

By the time the run was over, all path handling would take longer since
more paths needed filtering every time. By resetting paths at the end of
an API run, we prevent a given 'project' from polluting another one's
runtime and performance once the API successfully returns.

This likely makes rebar3 a bit more usable as an API, and such path leak
wouldn't impact normal projects in any significant way since they tend to
remain with one set of plugins and deps for their lifetime that won't change
too much.

[eproxus]

Works fine with the GRiSP plug-in:

$ rebar3 --version
rebar 3.7.0-rc1+build.4159.reffb6de6e0 on Erlang/OTP 21 Erts 10.0.8
$ rebar3 grisp deploy -n robot -v 0.1.0
===> Compiling mapz
===> Compiling bbmustache
===> Compiling grisp_tools
===> Compiling rebar3_grisp
===> Verifying dependencies...
===> Compiling robot
* Using custom OTP (cf4ef706)
===> Starting relx build process ...
===> Resolving OTP Applications from directories:
          /Users/alind/Stritzinger/Code/GRiSP/robot/_build/grisp/lib
          /Users/alind/Stritzinger/Code/GRiSP/robot/_checkouts
          /Users/alind/Stritzinger/Code/GRiSP/robot/_grisp/otp/21.0/install
          /Users/alind/Stritzinger/Code/GRiSP/robot/_build/grisp/rel
===> Resolved robot-0.1.0
===> Including Erts from /Users/alind/Stritzinger/Code/GRiSP/robot/_grisp/otp/21.0/install
===> release successfully created!
* Running pre_script
* Copying files...
* Copying release...
* Running post_script
foobar
===> Deployment of robot-0.1.0 complete

Also runs fine with _build and ~/.cache/rebar3/plugins removed to start from a clean slate.

[ferd]

Got the approval from @tothlac over Slack as well. Merging!