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
remote-svn svn: push tree diff in commit
remote-svn svn: push change user
remote-svn svn: push check for unfetched commits
remote-svn http: add svn http support

Includes support for both the old and new http API (1.7+). It switches
between the two using the same mechanism as libsvn (try the new first
and fall back on the old).

Uses the existing curl based http support used for the git http
transports. Thus all of the http.* config options also apply.
remote-svn http: read logs

Logs are read concurrently by using a fill function up to
http.maxrequests.