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
Add .gpg filename extension to in-repo encrypted keys

This will help distinguish keys encrypted with GPG from keys encrypted by
other means.  (For example, a future version of git-crypt might support
passphrase-encrypted keys.)
Make key files extensible, store key name in key file

Storing the key name in the key file makes it unnecessary to pass the
--key-name option to git-crypt unlock.

This breaks compatibility with post-revamp keys.  On the plus side,
keys are now extensible so in the future it will be easier to make
changes to the format without breaking compatibility.
Avoid unsafe integer signedness conversions when loading key file
Add get_directory_contents utility function
unlock: decrypt all possible keys when using GPG

It's no longer necessary to specify the -k option to unlock when
using GPG.  unlock will automatically decrypt all keys which the user
can access.
Rename add-collab, etc. to add-gpg-key, etc.

Since GPG support might be used by a single user and not necessarily
among collaborators.
Update usage message