If the directory we're about to process contains
reltool.config[.script] and the command to be applied is
'generate', then it's safe to process. We do this to retain the
behavior of specifying {sub_dirs, ["rel"]} and have "rebar generate"
pick up rel/reltool.config[.script]. Without this workaround you'd
have to run "rebar -r generate" (which you don't want to do if you
have deps or other sub_dirs) or "cd rel && rebar generate".

Always-on recursive application of all rebar commands causes too many
issues. Recursive application is required for:
1. dealing with dependencies: get-deps, update-deps, and compile of deps
   right after get-deps or update-deps
2. projects with a riak-like apps/ project structure and dev process

The vast majority of projects are not structured like riak. Therefore,
moving forward it's best to (by default) restrict recursive behavior to
dealing with deps. This commit does that and also adds command line and
rebar.config options for controlling or configuring recursion. Also, we
introduce two meta commands: prepare-deps (equivalent to rebar -r
get-deps compile) and refresh-deps (equivalent to rebar -r update-deps
compile). riak-like projects can extend the list of recursive commands
(to include 'eunit' and 'compile') by adding
{recursive_cmds, [eunit, compile]} to rebar.config.

Rebar, when it encounters a lib_dir directive, caches the current code
path, adds the libdir(s) and returns the cached copy of the path. When
rebar has finished processing that directory, it restores the cached
path. This is problematic in the below scenario:

        /(lib_dir)->G
  A -> B -> C -> D -> E
   \-> F -> D -> E

When rebar is finished processing B, it restores the code path to what
it was before it processed B, removing C, D, E and G from the code path.
This means when it comes to process F, neither D or E are in the code
path, so any header includes, rebar plugins or parse transforms will not
be in the code path. Without the lib_dir directive, rebar does no code
path cleanups, so everything works fine.

This change makes rebar only remove the explicit lib_dir code paths it
added and adds an inttest that replicates the above scenario.

Because rebar_core handles skipping apps, we had to specialcase the
handling in the case of update-deps because it has to do its own dep
handling. The way this was done is not particularly clean, but there
currently does not exist another way for a command to signal rebar_core
that it doesn't want rebar_core to pay attention to skip_apps.

With this change, however, you can update-deps even with local
conflicting changes/commits by simply skipping the deps you don't wish
to update, or whitelisting he ones you do wish to update.

This ensures that deps of deps are updated AFTER the dep listing them
is, so that a complicated project with many layers of deps will be
updated correctly. Any new deps encountered along the way are also
cloned, and THEIR deps are also evaluated.

Also added was conflict detection, if a dep has differing versions or
source information, inherited from different places, that will be logged
at the end of update-deps, along with the origin of each conflicting
dep.

- refactor plugin dirs code to be simpler and easier to read
- use erlang-mode's default (%%) comments for portability/consistency
- make sure erlang-mode's indenter is used so that a future whole
  buffer indent doesn't get messed up

If a plugin is in a dependency, rebar didn't search for it carefully
enough.

* allow plugins to print help message for implemented commands
* append core rebar.config options to common 'rebar help' message

Rename rebar_core functions for improved readability.
Remove redundant comments and blank lines.

Use erl_prim_loader:read_file_info instead of filelib:is_file to make
sure paths inside the escript archive are handled properly.

{port_specs, [{".*", "priv/foo.so", ["c_src/foo.c"], [{env, []}]}]}.

{pre_hooks,  [{"linux", compile, "c_src/build_linux.sh"}]}.
{post_hooks, [{"linux", compile, "c_src/build_linux.sh clean"}]}.

This patch modifies rebar_core to allow plugins to participate in the
pre and post processing steps, giving plugin authors more flexibility
and control.

Avoid overwriting custom config (passed with -C) when we are processing
the base_dir in rebar_core.

This patch fixes the warning logging when the number of missing plugins
is greater than one. The current code only works by accident, when a
single plugin is all that is missing.