Add a NUM_JOBS env var to builds

Closes #539
Use libgit2 for `git ls-files`

One forgotten spot to modify when migrating from the CLI to libgit2
Don't recompile git deps so frequently

The previous logic for recompiling any dependency was almost entirely based on
the mtimes of the relevant input files. This isn't quite what's desired for git
and registry dependencies because the mtime could be fluctuating while the files
aren't changing. For example:

1. Project A checks out git repo C at revision C1
2. Project A builds, records mtimes of C
3. Project B checks out git repo C at revision C2
4. Project B builds, records new mtimes of C
5. Project A is rebuilt, rebuilding C b/c mtimes are different

In step 5 here C should not be rebuilt because the revision didn't actually
change.

This commit alters git/registry dependencies to completely bypass the --dep-info
emitted and only rely on the git/registry source to inform what the fingerprint
is. This is the revision/version, respectively, and should be all that's
necessary to track changes to the repo and trigger a rebuild.
Don't blow away checked out git repos

This primarily blows away all *submodules* as well, which sometimes can be quite
large and take some time to update. Instead, re-use an existing checkout, just
reset it to the right revision if possible.

Also, move the submodule update step to occur unconditionally to account for
corrupt submodule checkouts or interrupted downloads. This update step should be
much faster than `git submodule update` because we're using libgit2, so yay!
auto merge of #542 : alexcrichton/cargo/issue-539, r=brson

Closes #539
auto merge of #547 : alexcrichton/cargo/git2-for-package, r=brson

One forgotten spot to modify when migrating from the CLI to libgit2
auto merge of #548 : alexcrichton/cargo/frobbing-git-deps, r=brson

The previous logic for recompiling any dependency was almost entirely based on
the mtimes of the relevant input files. This isn't quite what's desired for git
and registry dependencies because the mtime could be fluctuating while the files
aren't changing. For example:

1. Project A checks out git repo C at revision C1
2. Project A builds, records mtimes of C
3. Project B checks out git repo C at revision C2
4. Project B builds, records new mtimes of C
5. Project A is rebuilt, rebuilding C b/c mtimes are different

In step 5 here C should not be rebuilt because the revision didn't actually
change.

This commit alters git/registry dependencies to completely bypass the --dep-info
emitted and only rely on the git/registry source to inform what the fingerprint
is. This is the revision/version, respectively, and should be all that's
necessary to track changes to the repo and trigger a rebuild.
auto merge of #549 : alexcrichton/cargo/git-no-delete, r=brson

This primarily blows away all *submodules* as well, which sometimes can be quite
large and take some time to update. Instead, re-use an existing checkout, just
reset it to the right revision if possible.

Also, move the submodule update step to occur unconditionally to account for
corrupt submodule checkouts or interrupted downloads. This update step should be
much faster than `git submodule update` because we're using libgit2, so yay!
Move to rustdoc instead of ruby's middleman

* All markdown files are now rendered with `rustdoc` into HTML
* A JS syntax highlighter, prism, is included for TOML syntax highlighting.
* A new makefile target, `make doc`, will build docs into `target/doc`
auto merge of #550 : alexcrichton/cargo/rustdoc, r=brson

* All markdown files are now rendered with `rustdoc` into HTML
* A JS syntax highlighter, prism, is included for TOML syntax highlighting.
* A new makefile target, `make doc`, will build docs into `target/doc`

preview: http://people.mozilla.org/~acrichton/crates.io/doc/

Closes #524
Implement a registry source

# cargo upload

The cargo-upload command will take the local package and upload it to the
specified registry. The local package is uploaded as a tarball compressed with
gzip under maximum compression. Most of this is done by just delegating to
`cargo package` The host to upload to is specified, in order of priority, by a
command line `--host` flag, the `registry.host` config key, and then the default
registry. The default registry is still `example.com`

The registry itself is still a work in progress, but the general plumbing for a
command such as this would look like:

1. Ensure the local package has been compressed into an archive.
2. Fetch the relevant registry and login token from config files.
3. Ensure all dependencies for a package are listed as coming from the same
   registry.
4. Upload the archive to the registry with the login token.
5. The registry will verify the package is under 2MB (configurable).
6. The registry will upload the archive to S3, calculating a checksum in the
   process.
7. The registry will add an entry to the registry's index (a git repository).
   The entry will include the name of the package, the version uploaded, the
   checksum of the upload, and then the list of dependencies (name/version req)
8. The local `cargo upload` command will succeed.

# cargo login

Uploading requires a token from the api server, and this token follows the same
config chain for the host except that there is no fallback. To implement login,
the `cargo login` command is used. With 0 arguments, the command will request
that a site be visited for a login token, and with an argument it will set the
argument as the new login token.

The `util::config` module was modified to allow writing configuration as well as
reading it. The support is a little lacking in that comments are blown away, but
the support is there at least.

# RegistrySource

An implementation of `RegistrySource` has been created (deleting the old
`DummyRegistrySource`). This implementation only needs a URL to be constructed,
and it is assumed that the URL is running an instance of the cargo registry.

## RegistrySource::update

Currently this will unconditionally update the registry's index (a git
repository). Tuning is necessary to prevent updating the index each time (more
coming soon).

## RegistrySource::query

This is called in the resolve phase of cargo. This function is given a
dependency to query for, and the source will simply look into the index to see
if any package with the name is present. If found, the package's index file will
be loaded and parsed into a list of summaries.

The main optimization of this function is to not require the entire registry to
ever be resident in memory. Instead, only necessary packages are loaded into
memory and parsed.

## RegistrySource::download

This is also called during the resolve phase of cargo, but only when a package
has been selected to be built (actually resolved). This phase of the source will
actually download and unpack the tarball for the package.

Currently a configuration file is located in the root of a registry's index
describing the root url to download packages from.

This function is optimized for two different metrics:

1. If a tarball is downloaded, it is not downloaded again. It is assumed that
   once a tarball is successfully downloaded it will never change.
2. If the unpacking destination has a `.cargo-ok` file, it is assumed that the
   unpacking has already occurred and does not need to happen again.

With these in place, a rebuild should take almost no time at all.

## RegistrySource::get

This function is simply implemented in terms of a PathSource's `get` function by
creating a `PathSource` for all unpacked tarballs as part of the `download`
stage.

## Filesystem layout

There are a few new directories as part of the `.cargo` home folder:

* `.cargo/registry/index/$hostname-$hash` - This is the directory containing the
  actual index of the registry. `$hostname` comes from its url, and `$hash` is
  the hash of the entire url.

* `.cargo/registry/cache/$hostname-$hash/$pkg-$vers.tar.gz` - This is a
  directory used to cache the downloads of packages from the registry.

* `.cargo/registry/src/$hostname-$hash/$pkg-$vers` - This is the location of the
  unpacked packages. They will be compiled from this location.

# New Dependencies

Cargo has picked up a new dependency on the `curl-rust` package in order to send
HTTP requests to the registry as well as send HTTP requests to download
tarballs.
Implement Sha256 bindings

These are used to verify the downloads of packages from the registry.
Test the output of `cargo package`
Add proxy configurations
Add tests exercising the registry source
More and more tests (cargo upload)
Use a different curl-rust for now

Waiting on fixes to be merged upstream
Fix tests on windows