Add utility functions for big-endian int storage

Use instead of htonl().
Major revamp: new key paradigm, groundwork for GPG support

The active key is now stored in .git/git-crypt/key instead of being
stored outside the repo.  This will facilitate GPG support, where the
user may never interact directly with a key file.  It's also more
convenient, because it means you don't have to keep the key file
around in a fixed location (which can't be moved without breaking
git-crypt).

'git-crypt init' now takes no arguments and is used only when initializing
git-crypt for the very first time.  It generates a brand-new key, so
there's no longer a separate keygen step.

To export the key (for conveyance to another system or to a collaborator),
run 'git-crypt export-key FILENAME'.

To decrypt an existing repo using an exported key, run 'git-crypt unlock
KEYFILE'.  After running unlock, you can delete the key file you passed
to unlock.

Key files now use a new format that supports key versioning (which will
facilitate secure revocation in the future).

I've made these changes as backwards-compatible as possible.  Repos
already configured with git-crypt will continue to work without changes.
However, 'git-crypt unlock' expects a new format key.  You can use
the 'git-crypt migrate-key KEYFILE' command to migrate old keys to the
new format.

Note that old repos won't be able to use the new commands, like
export-key, or the future GPG support.  To migrate an old repo, migrate
its key file and then unlock the repo using the unlock command, as
described above.

While making these changes, I cleaned up the code significantly, adding
better error handling and improving robustness.

Next up: GPG support.
Rename some functions instead of overloading them

It's more clear this way.
Use successful_exit() helper for testing system() return value
Fix a typo in an error message
Plug a file descriptor leak if fork() fails

(Not that we really care if that happens ;-) but it's good to be correct.)
Initial GPG support

Run 'git-crypt add-collab KEYID' to authorize the holder of the given
GPG secret key to access the encrypted files.  The secret git-crypt key
will be encrypted with the corresponding GPG public key and stored in the
root of the Git repository under .git-crypt/keys.

After cloning a repo with encrypted files, run 'git-crypt unlock'
(with no arguments) to use a secret key in your GPG keyring to unlock
the repository.

Multiple collaborators are supported, however commands to list the
collaborators ('git-crypt ls-collabs') and to remove a collaborator
('git-crypt rm-collab') are not yet supported.
Fix include guards to not start with _

Since such names are reserved, technically.
Makefile: don't compile with -ansi

Fixes build on Cygwin due to [1].  Closes #19 on GitHub.

[1] https://cygwin.com/ml/cygwin/2014-01/msg00130.html
Lay groundwork for Windows support

Move Unix-specific code to util-unix.cpp, and place Windows equivalents
in util-win32.cpp.  Most of the Windows functions are just stubs at
the moment, and we need a build system that works on Windows.
New exec_command() that takes command as array instead of string

This abstracts away the details of argument quoting, which differs
between Unix and Windows.

Also replace all uses of the system() library call with exec_command().
Although system() exists on Windows, it executes the command via cmd.exe,
which has ridiculous escaping rules.
Finish implementing Windows utility functions

This completes Windows support, except for the build system and
documentation.
Add umask and rename compatibility wrappers for Windows

umask() doesn't exist on Windows and is thus a no-op.

rename() only works if the destination doesn't already exist,
so we must unlink before renaming.
Minor pedantic changes to I/O code

Don't bother checking for !in because the gcount() check is quite
sufficient and having both checks was confusing.

Make some variables const because they can be.
Add a minor TODO comment
Make 'add-collab' safe with filenames starting with '-'
Add touch_file() utility function
Initial implementation of 'git-crypt status'

'git-crypt status' tells you which files are and aren't encrypted and
detects other problems with your git-crypt setup.

'git-crypt status -f' can be used to re-stage files that were incorrectly
staged unencrypted.

The UI needs work, and it needs to also output the overall repository
status (such as, is git-crypt even configured yet?), but this is a
good start.
Add parse_options helper for parsing cmd line args
Initial implementation of multiple key support

The init, export-key, add-collab, and unlock commands now
take an optional -k (equivalently, --key-name) option to
specify an alternative key.  Files can be encrypted with
the alternative key by specifying the git-crypt-KEYNAME filter
in .gitattributes.  Alternative key support makes it possible
to encrypt different files with different keys.

Note that the -k option to unlock is temporary.  Unlock
will eventually auto-detect the name of the key you're
unlocking, either by looking in the symmetric key file,
or by scanning the .git-crypt/keys directory.

Note that the layout of the .git/git-crypt and .git-crypt
directories has changed as follows:

 * .git/git-crypt/key is now .git/git-crypt/keys/default
 * .git-crypt/keys is now .git-crypt/keys/default