Mostly changing the format of debug messages, fixing one URL that was
bad in a warning.

Since we switched to DIAGNOSTIC=1 in the crashdump, the only way to make
DEBUG=1 discoverable (outside of docs) is in the help provider.

Fixup plugin upgrade autoupdate

Didn't handle tuple-based dep definitions right

Run pkg updates on plugin upgrades

Upgrading dependencies already checked for package updates before running
the upgrade task. Plugins didn't have that mechanism in place and that
made upgrading plugins over hex trickier since users could be stuck a
long time without running an update manually.

This fix mostly readapts existing dep code to the context of plugins to
look them up one at a time and run the update as part of the upgrade.

Rework DEBUG=1 mode to be user-centric output and introduce separate DIAGNOSTIC=1 mode for implementer-level logging

This should cover most cases, including hooks.
What this specifically does is change some less useful messages for more
contextualized ones, including tying specific configurations to actions
taking place. This is particularly visible in hooks, and hopefully
provides some amount of discoverability.

Also of note:
- ebin/ directory copying is called explicitly when done since people
  have issues with that
- paths for compiled files are made relative since the analysis list
  shows the full paths already
- hooks are a bit more verbose but also more useful.

Move most stuff that have to do with effectiveness to the debug
level, and some stuff that has to do with implementation details to
diagnostics

The change was possible since R13B04 when macros with many arities
became supported. We never really cleaned that stuff up before so I'm
picking it up while I'm updating that code

Diagnostic mode is intended to be used for rebar3 maintainers to debug
and understand issues. It shows all the things and all the data and
works with the assumption that people has intent to use the source code
to debug things.

Debug mode is promoted to user-oriented debugging, based on the idea
that what they care about is figuring out their interactions with the
tool. A major improvement in usability would be to directly tie the user
config to the interpreted config (ie merged profiles) to clearly hint at
seen rebar3’s behaviour.  If the debug output can show that and even tie
some behaviours to the config value that impacts things, we could get
some discoverability out of it too, something missing from declarative
tools like this.

Make rebar3 templates check for name clashes

Co-authored-by: Fred Hebert <mononcqc@ferd.ca>

Update link for Rebar 2.x to Rebar3

The link was missing a `tutorials` in the path.

This commit changes rebar3 to check for name clashes of the
modules created from its templates with existing Erlang modules
to produce a non-blocking warning for each clashing module.

Patch `rebar_base_compiler` to handle extensions with no leading dot

Handle unicode in author's name in templates

Specify dependencies for MIB files

This is required for compile order to be maintained in a post-3.14
world.

Ignore `global` and `default` in empty profiles warning for `as`

Update README.md

Only one of the two plugin system links seems to work, the other 404's. I think the proposed link may go to the equivalent place?

Use infinity timeout for rebar_compiler_epp resolve call

Change xref paths to only those of runtime deps

This commit adds new checks in the `set_paths` test case related to
runtime apps and their path handling with the `runtime` target in
`rebar_paths`. These new checks also hope to increase the coverage
of the changes done to the xref provider in this same PR (#2354).

This commit also adds some new helper functions to help deal with
future changes related to these new checks (i.e., changes related to
the runtime apps), besides fixing a problem when looking for the
first instace of an app/dep/plugin in the path while testing.

Add `alias` to example `rebar.config.sample`

Update README with supported Erlang/OTP versions

Fix `dialyzer` warning output for option `unknown`

... and e.g. an unknown type is detected

Add xref_ignores to sample config file

Especially for those that rely on the sample rebar.config from the get-go

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.

Fix lock file not being generated when no deps are present in the config