Top-level `freeze` command freezes dependency versions

Add new top-level `freeze` command, which resolves the dependencies to exact
versions and writes a `constraints` section to `cabal.config`. This causes
future builds to use the same fully constrained dependencies.

The command takes a number of options related to resolving dependencies,
namely, `--solver`, `--max-backjumps`, `reorder-goals` and
`--shadow-installed-packages`. These are used to create an `InstallPlan` in
much the same way that `install` does so. The `InstallPlan` is converted to a
list and all `PlanPackage`s are inspected to determine their exact version.
These versions are then either written to `cabal.config` or to standard output
depending on the presence of `--dry-run`.

Limitations in resolving dependencies
-------------------------------------

In order to keep the initial implementation of this new command simpler, a
number of options are not yet supported.  There should be no great difficulty
in supporting the options `--flags`, `--enable-{tests,benchmarks}`,
`--constraint` and `--preference`.  However, the options concerned with
compilers may prove more difficult.

Different versions of GHC ship with different library versions, the
constraints that are written currently include all dependencies, including
`base`. This prevents the constraints, as written, from being used with
alternate versions of GHC.

There are three solutions to this problem: 1) have the user edit the
constraints section, 2) exclude certain packages from the list of constraints,
3) develop a mechanism for per-arch-os-compiler constraining. As neither (2)
nor (3) have been developed we default to (1).

The lack of a good story for per-compiler constraints has lead to the options
`--with-compiler`, `--ghc`, `--uhc` et al, not being supported.

Further limitations:
--------------------

 - The `cabal.config` file is completely overwritten. Just the `constraints`
   section should be overwritten.
cabal upload: use ByteString instead of String

The difference is seen nicely on Raincat package (9MB tarball):
    $ /usr/bin/time cabal upload --check Raincat-1.1.1.3.tar.gz
    39.92user
    0.38system
    4:02.50elapsed
    16%CPU (0avgtext+0avgdata 1855712maxresident)k

Insane amounts of used RAM (1.8GB) seem to stem from 'String'
inefficiency especially on 64-bit platforms where overhead is
about 16 times:

 - 97% of CPU time is taken by GC scans (according to +RTS -sstderr)
 - 9MB tarball would take ~150MBs of RAM, 100MB tarball would...

Attempt to pack them into HTTP headers leads to further growth.

The patch only changes underlying structure to ByteString.Lazy.Char8:
    $ /usr/bin/time patched-cabal upload --check Raincat-1.1.1.3.tar.gz

    0.25user
    0.16system
    4:28.61elapsed
    0%CPU (0avgtext+0avgdata 66864maxresident)k

In short: 1.8GB -> 66MB RAM reduction + 16% -> 0% CPU usage.

Reported-by: "Mikhail S. Pobolovets" <styx.mp@gmail.com>
Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>
Add a .travis.yml config
Merge branch 'cabal-upload-to-bytestring' of https://github.com/trofi/cabal
Add 'freeze' command

The freeze command freezes the versions of all dependencies.
Brief documentation for the freeze command
Distribution.Simple.Setup: Clean up + refactor list
Merge pull request #1617 from benarmston/documentation-for-cabal-freeze

Brief documentation for the freeze command
Typos.
Merge pull request #1618 from nh2/refactor-jobs-parser

Distribution.Simple.Setup: Clean up + refactor list
More consistent formatting.
Use 'optionNumJobs' in D.C.Setup.