remote-svn: add fetched reply and fetch-unknown capability to the remote-helper

fetched is returned by the remote-helper in response to a series of
fetches which indicates which ref has been updated and to what SHA1
value. This way a remote can:

1. At list indicate that a number of refs exist, but with an unknown
   value, by using the existing "? <ref>\n" reply.
2. Git then asks for interesting refs with "fetch <null_sha1> ref\n"
3. The remote helper fetches the refs and replies with "fetched <sha1>
   ref\n"

remote-svn requires this functionality as it creates commits directly as
it fetches refs, but can't know the final sha1 value until the ref is
completely up to date.

This also adds a fetch-unknown capability which is used by the helper to
require that git supports the fetched reply.
remote-svn: send through the standard options to a remote helper for list

This way the verbose and progress flags are pushed through to the helper
before the list command.

This also means that verbose and progress are sent through twice (before
list and before fetch/push) for most transport usage, but helpers
shouldn't have a problem with this.
remote-svn: add simple in memory svn diff create and apply

apply_svndiff applies a svn diff V0/1 to an in memory copy of the source
copying the output to a string buffer.

create_svndiff creates a simplistic SVN v1 diff which contains a gzipeed
copy of the target (ie not really a diff).

These are sufficient for now for remote-svn, but should probably be
merged with vcs-svn and/or use libsvn itself, but that is a larger
undertaking.
remote-svn: add helper functions for manipulating svn commits to libgit

SVN commits are git commits created for each SVN commit that modifies a
given branch. They have a few special properties:

1. Their first parent is the actual git commit created that the user sees
2. Their second parent is the previous svn commit for this branch. This
   is only present if there was a previous svn commit and this commit
isn't a add/copy/replace to the root which replaces a previous branch.
3. They have a branch <folder> header which contains the SVN path
   relative to the SVN root. This contains the path according to SVN
which may be different than the refs/svn ref as git is more restrictive
wrt to allowed characters.
4. They have a revision <revno> header which contains the SVN revision
   number.

These functions are added to libgit as they are shared by remote-svn
(seperate exe) and its helper (bulitin).
remote-svn: add remote-svn--helper

remote-svn--helper is used by remote-svn during a fetch to create git
objects, commits, svn commits, etc. remote-svn uses a seperate helper
process so it can run gc --auto after every 1000 or so commits. It can't
create git objects itself after running gc --auto as repack invalidates
the local git cache.

The helper reads one command per line in the same manner as remote
helpers. Any arguments which may contain newlines are quoted using c
quote.

The commands are:
- checkout: checks a given svn revision out to the internal index and
  saves the revision as the branch parent
- reset: resets the internal index and branch point
- add-dir: called when svn adds a directory. Creates a .gitempty file
  within the folder so that git creates the folder on checkout. This
file is later removed by any subsequent add-dir or add-file commands
within this folder.
- delete-entry: deletes a file/folder
- commit: creates a git and svn commit using the earlier checkout as the
  parent
- branch: creates a svn commit which points to an earlier fetched git
  commit. Used when a branch is created in SVN without any further
modifications in that revision.
- report: echos back a fetched reply to feed to git fetch
remote-svn: add skeleton remote-svn

Just replies to capabilities and options for the moment.
remote-svn: handle list

On list remote-svn will look to see what folders exist at the latest rev
and return the equivalent git references. The list of folders and
mapping to git references is given by remote.<remote>.map. The format of
this is <relative svn path>:<git refspec> and there can be multiple
mappings. For example:

remote.origin.map = trunk:refs/heads/trunk
remote.origin.map = branches/*:refs/heads/*
remote.origin.map = tags/*:refs/tags/*

The map should follow the same rules as a refspec (only one * and both
sides must have one or none, * can appear as any path component, etc).
If no map is provided, then a default rule mapping the fetch url to
refs/heads/master is used. HEAD is hardcoded as a symref to
refs/heads/master.

The revision used is the minimum of remote.<remote>.maxrev or the latest
revision in the remote.

This commit adds the interface used by remote-svn for the protocol
specific handling, but none of the protocol specific handlers yet.
remote-svn: add authors file

svn.authors specifies an authors file in the same format as git-svn and
git-cvs:

username = Full Name <email@example.com>

Comments begin with # and continue to the end of the line.
remote-svn: list out commits

The list of commits to fetch is generated by:

1. Remote-svn calls proto->read_logs.
2. The protocol handler calls next_log repeatably until it returns
   non-zero indicating that there are no more logs needed at the moment.
3. Logs should be generated in newest to oldest order calling cmt_read
   as each commit is found.
4. When a given log is finished, the protocol handler calls log_read,
   which decides if more logs are needed to find/follow the copy source.

remote-svn detects a copy by noting that the log stopped early. It then
re-requests that single commit to get the copysrc and then schedules a
log for the copied data if needed.
remote-svn: fetch commits

Commits are fetched by:

1. remote-svn spawns git remote-svn--helper
2. Hands off to the protocol handler to grab updates by calling
   proto->read_updates
3. The protocol handler collects updates to collect by calling
   next_update
4. The protocol handler appends the update to update->head as a command
   stream to feed to the helper
5. Once the update is complete, the protocol handler calls update_read.
   This then either feeds it to the helper or buffers the commands to
feed to the helper later.

Multiple updates can be fetched concurrently and they can finish out of
order. Updates are feed to the helper in the order in which next_update
generates them. If an update finishes earlier than an earlier update,
then it is buffered in the finished_updates list.

next_update limits the protocol handler to only grab up to 1000 updates.
After these have all been finished, the protocol handler returns from
read_updates, remote-svn finishes the helper and runs gc --auto. This
process is then repeated until there are no more updates to fetch.
remote-svn: add find_copy_source

find_copy_source is used by push to find the nearest ancestor that is
already in svn. It prefers the current commit at HEAD for that branch,
but will otherwise will find the newest ancestor in svn.
remote-svn: push commits

remote-svn pushes ref updates to svn by finding some path from the
nearest commit in svn to the new head. The nearest commit is preferably
the current commit at HEAD, but failing that the newest ancestor.

If the target is empty then it will delete the current folder. If the
folder doesn't exist it will be created first. If the target exists, but
is not an ancestor and the user requested a force push, a replace is
used (delete and add+copy in the same commit).
remote-svn: push the tree difference

Changes to files upload the entire new file. If svn.eol is set, it is
first converted to that eol format.

New files are elided if they begin with .git. This way git specific
files are not pushed into svn (e.g. .gitignore, .gitmodules,
.gitattributes, .gitempty). However if the files are created first in
svn, then they can be modified/deleted in git. Likewise file deletes are
only pushed through to svn if the file also exists in svn. This is
tracked by using the seperate tree in the svn commit.
remote-svn: use more appropriate push log messages

When pushing tags, the tag message is used. When pushing commits the
commit message is used if it's not already in svn (e.g. new branch). In
the latter case and also branch deletion the empty message is used. This
can be configured with svn.emptymsg.
remote-svn: change to an appropriate user for push

If a authors file is specified, a username is looked up by matching the
email address. For branch creation/deletion the default credential is
used (i.e. when the empty message is used).

If there is no authors file, the default credential is always used.
remote-svn: check for unexpected commits on push

This adds a check before the push starts to see if there any commits
since the last fetch.

There is also a check after pushing each commit to see if there were any
commits pushed during the push. If there were any, then the push fails.
The user then has to fetch, rebase/merge (or push --force) and try
again. This is conceptually the same as another user updating a ref
between the initial list and the ref update with a git push. The major
difference is that svn will accept two commits at the same time as long
as they don't touch the same files.
remote-svn svn: add initial svn:// protocol support

This adds basic support for the svn protocol to connect to a server as
anonymous or authenticated as well as listing the available branches at
HEAD.
remote-svn svn: read logs

Multiple logs are read concurrently in worker threads. The number of
concurrent logs is given by svn.maxrequests.
remote-svn svn: read updates

Updates are fetched concurrently in worker threads like the logs.
remote-svn svn: push commits