Avoid passing more than one instance of ERL_LIBS to child processes

This commit fixes issue #98 by removing the ERL_LIBS and REBAR_DEPS_DIR
from the list of environment variables exported by the rebar_port_compiler
plugin.
Incorrect REMSH args when sname is used

When a node is configured with -sname in app.config or sys.config the
REMSH_NAME_ARG and REMSH_REMSH_ARG arguments are incorrect due the
assumption that the node name always contains '@'.

To fix the bug, the script tries to find '@' and then compose the
arguments acording to node name type. If in long name mode the
script can't compose a correct node name exits with warning.
Make REMSH node run in hidden mode

To avoid problems with REMSH node being visible from another nodes
starts it in hidden mode (erl -hidden).
Make update-deps traverse deps breadth-first, top-down

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.
Allow specification of module dependencies for appups

The order in which modules, within an application, are loaded can be
important. This patch adds allows the specification of module
dependencies such that generate .appup/.relup scripts will load a
module's dependent modules before itself.

To use:

in rebar.config, add a module_deps

{module_deps, [{ModuleName, [DependentModuleName, ...]}]}.

ModuleName is the name of any module, followed by a list of module
names that it depends on.
Ignore skip_deps during update-deps as it has no meaning
Change how update-deps updates a git branch

Previously, update-deps on a dep tagged as {branch, ...} would do the
following:

  git fetch
  git checkout -q origin/<branch>

If you were already on that branch, the repo would end up in detached
head state. This is kind of annoying if you're doing local development.

This patch changes the behaviour to be

  git fetch
  git checkout -q <branch>
  git pull --ff-only --no-rebase -q <branch>

The intent of this is to move the branch's HEAD forward to match
upstream without destroying any local commits or changes, and without
accidentally causing merges or rebases. It will fail if the operation
can not be performed without losing history, merging or rebasing.

The previous behaviour has been around a very long time:

https://github.com/rebar/rebar/commit/064195dc5a90f5b0cc3ae92e8373671b0043033f#L0R308

It also exactly mirrors the download_source case, which is not really
true. With git tags and SHAs, one can assume that they don't change, but
branches move all the time.
Make update-deps honor apps= and skip_apps=

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.
Fix skip check for deps not present
Address review comments and add inttest for update-deps
Typo
Merge pull request #142 from Vagabond/adt-update-deps

Make update-deps traverse deps breadth-first, top-down
'current_command' has to be stored in xconf
rebar_deps: fix Dialyzer warning
rebar_deps: 'depowner' has to be stored in xconf
rebar_deps: fix overly long lines
Fix issues introduced in #137 (4dfdd72)

* fix Dialyzer warning
* fix formatting
Fix update-deps with certain forms of the {tag, ...} type

Sometimes tags like 1.1-3-g3af5478 or d20b53f0 are encountered. The
first is the output of 'git describe', and the second is just a regular
git SHA. git fetch --tags will not pull these down, so do a full git
fetch instead.
Don't over-aggressively clean the code path in the presence of lib_dir directives

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.
Don't badmatch if a path we think we added isn't in the code path