To further support OTP releases I have added support for generating
application appup files. These include instructions that systools uses
to generate a relup file which contains the low level instructions
needed to perform a hot code upgrade. My goal with this module is to
produce "good enough" appup files or at least a skeleton to help one get
started with something more complex. If an appup file already exists for
an application this command will not attempt to create a new one.

Usage:
$ rebar generate-appups previous_release=/path/to/old/version

Generally this command will be run just before 'generate-upgrade'.

If an app uses -include_lib for its own included files, compilation
fails if the app directory isn't in $ERL_LIBS because code:lib_dir/1
will return an error. An absolute path needs to be added to code path
instead of just "ebin".

In git origin/HEAD is a pointer to the default branch.  This patch
allows two alternatives to explicitly specifying "HEAD" in git VC specs.

The first is a 2 arity form {git, Url} and the second is {git, Url, ""}
which worked in pre-update-deps rebars.

I have moved these macros from rebar_core.erl to rebar.erl
in order to prevent eunit tests from failing (which they
currently are).

To support OTP release upgrades I have added support for building
upgrade packages. Support for this is included in the
rebar_upgrade module, specifically generate_upgrade/2. It requires
one variable to be set on the command line 'previous_release' which
is the absolute path or relative path from 'rel/' to the previous
release one is upgrading from. Running an upgrade will create the
needed files, including a relup and result in a tarball containing
the upgrade being written to 'rel/'. When done it cleans up the
temporary files systools created.

Usage:
$ rebar generate-upgrade previous_release=/path/to/old/version

This also includes a dummy application that can be used to test
upgrades as well as an example.

Special thanks to Daniel Reverri, Jesper Louis Andersen and
Richard Jones for comments and patches.

This change makes it possible to type the beginning (the prefix) of a
command name and rebar will guess the full name of the command,
thereby saving the user precious keystrokes.  As long as the prefix
matches only one command, rebar runs that command, otherwise rebar
prints a list of candidate command names. The "-" character is
considered to be a word separator and the prefix matching is done per
word.

Example prefix matches:

    co       ==> compile
    cl       ==> clean
    create   ==> create
    create-a ==> create-app
    c-a      ==> create-app
    c-app    ==> create-app

On one project I have a need to specify port_sources on R14 only
and on another different project port_sources for Darwin and Linux.
To this end add support to handle tuples of the form
{ArchRegex, PortSource} in the port_sources list, eg:

    {port_sources, [{"R14", ["c_src/*.c"]}]}.

Add flags to rebar_utils:sh to control output and error handling.
Replace calls to os:cmd with calls to rebar_utils:sh.

This patch remedies an issue where the ebin directory would be
erroneously created as a file by the first "mv" command in
rebar_protobuffs_compile.erl [line 106] if the ebin file did not
exist at the root application level.

In essence, the patch ensures that the ebin directory exists at
the application directory level before any "mv" commands are
executed. The following code was inserted at line 106:

    ok = filelib:ensure_dir(filename:join("ebin","dummy")),

Prevent overlooking a compilation warning by removing the target beam
file after fail_on_warning failure.

abnfc is an ABNF parser generator.
Options are:
	- doc_root (defaults to "src")
	- out_dir (defaults to "src")
	- source_ext (defaults to ".abnf")
	- module_ext (defaults to "")

Add support for defining template variables of the following form:

{variables, [{appid, "mochiwebapp"},
         {author, "Mochi Media <dev@mochimedia.com>"},
         {year, "2010"},
         {version, "0.1"},
         {port, 8080},
         {dest, "{{appid}}"}]}.

Where dest may be overridden on the commandline but will default to
being the appid. Mochiweb uses this so that we can create new
projects from the template in a configurable directory.

So

$ rebar create template=mochiwebapp dest=foo appid=bar

I thought about special casing dest but figured it might be generally
useful to be able to nest template vars.

However this patch only does one level of resolution. So if

{variables, [{foo, "{{bar}}"},
                {bar, "{{foo}}"}]}.

then bar will end up being the literal string {{bar}} and foo the
literal string {{foo}}.

mustache:render("{{banan}}", dict:from_list([{banan, true}])).

** exception error: no function clause matching mustache:escape(true,[])
     in function  erl_eval:do_apply/5
     in call from erl_eval:expr/5
     in call from erl_eval:expr/5
     in call from mustache:render/3