(some are not "wrong" per se, but incomplete)

This commit changes mainly the `rebar_paths` module by adding a
new `runtime` target. When using that target, `rebar_paths:get_apps/2`
will, for each project app, find all their `applications` and
`included_applicactions` and filter those that could be found
in rebar3's state.

The app data, when set by `rebar3_app_discover` basically does not
include the modules if it was derived from the .app.src file, even if at
a later point the modules were compiled.

Since there is currently no clear way to add that information reliably
across all compiler versions in all types of compilers, we simply clear
the cache and re-derive the information when required.

This might have a small performance cost, but is required for
correctness whenever an application's first build is run. Specifically,
this bug was detected when a plugin included lager's parse transform,
and the application itself also required it, but two distinct versions
were needed.

This patch finalizes fixing this issue.

- 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 the latter one
explains the 40% overhead in test runs: since rebar3 calls rebar3 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.

Some finishing touch to that code

Also handle some formatting

Move path management out of rebar_utils manual code path function
handling (which we leave there for backwards compat), and centralize
them to allow easier coordination of paths between plugins and deps.

On top of path handling, do a check of loaded modules to only purge and
reload those that actually need it done in order to prevent all kinds of
weird interaction and accidental purge kills. It also allows the
possible cohabitation of both at once, with a "in case of conflict pick
X" as a policy

Changing path handling in providers also highlighted a bunch of bugs in
some tests and appears to fix some in other providers, specifically
around plugins.