When running 'rebar qc' or 'rebar eunit', we were erroneously fetching
erl_opts more than once.

test_compile/3 is used by eunit and qc, but the comment was only
referring to 'rebar eunit'.

* update files
* fix Dialyzer warning
* unconditionally enable info fil
* clean-up inconsistencies
* use term_to_binary compression
* use try...catch instead of case...catch...of
* do not write build info file if the graph is unmodified
* store info file as <base_dir>/.rebarinfo
* properly support list of compile directives
* fix regressions:
 - Fix a bug in handling of files to compile first.
 - If a file that is depended upon itself depends on other files, make sure
   those are compiled first. While at it, rename variables for correctness.
   Reported-by: David Robakowski
 - Make sure that FirstFiles has no dupes and preserves the proper order.
 - headers referenced via -include_lib() were not properly resolved to absolute
   filenames
 - .erl files found in sub dirs of src_dirs were not properly resolved to
   absolute filenames

* Do not parse source files twice while checking for relationship.
* Keep files relationships in a graph.
* The option 'keep_build_info' is introduced. When set to 'true'
  the graph will be kept in ebin/.rebar.build.info and will be
  used by further compiler calls. The default is 'false'.

Option takes either 'true' or a numeric seed value. If true is passed, a
random seed is generated and used. The numeric seed value is for
repeatability.

The idea here is to root out test suites that are order dependant, or
that fail in the presence of certain orderings.

If the syntax error is in a .hrl file, then the reported error message
is not as useful because it's not clear which .erl file was being
compiled. We can fix that easily by first printing what source file was
being processed. We don't change the actual error message, so this will
still work with your editor of choice for jumping to the right line.

Before
------

Success:
Compiled src/foo.erl

Failure:
include/foo.hrl:10: syntax error [...]

After
-----

Success:
Compiled src/foo.erl

Failure:
Compiling src/foo.erl failed:
include/foo.hrl:10: syntax error [...]

erlydtl implemented 'binary' option. Add new clause for {binary, false}.

Remove experimental flag from:
* qc compile_only=true
* eunit compile_only=true
* src/foo.app.src.script
* eunit tests=

Adapt rebar_erlydtl_compiler to handle warnings emitted by
erlydtl:compile/3.

While at it, update getopt.erl to git rev 78eda3b.

To avoid treating plugins' info/2 functions as commands, we catch calls
to 'rebar info'. Previously (4b8c81fb) we simply printed the help
string, but it's much more informative to print the following:
Command 'info' not understood or not applicable

It's easier to modify the list with each command on a separate line.
The shell completion scripts have already been modified that way.

Previous generate-upgrade required renames in rel/ directory:

    rebar generate
    ...changing code...
    mv rel/<release> rel/<release_prev>
    rebar generate
    rebar generate-upgrade previous_release=<release_prev>

With the proposed changes you can now do the same without moving things:

    rebar generate # default target dir: rel/<release>
    ...changing code...
    rebar generate target_dir=<release_new>
    rebar generate-upgrade target_dir=<release_new> previous_release=<release>

Avoid getting erl_opts twice in test_compile/3, and make sure the
correctly filtered (platform_define, etc.) version is used.

rebar used to mistakenly report plain version strings like
{vsn, "1.0.0"} as follows:
DEBUG: vcs_vsn: Unknown VCS atom in vsn field: "1.0.0"

Properly detect unknown/unsupported version terms and abort
if we encounter one.

While at it, rename a variable in vcs_vsn/3 to be non-misleading.

As discussed with Martin Schut, remove support for
{app_name, "vsn", {fossil, "url", latest}.

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.

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.

* fix Dialyzer warning
* fix formatting