[PATCH] Speed up client by re-using RA session connections

A patch in progress, for demonstration and your feedback.

Since long ago we've thought about letting the client, through the
libsvn_client API, share a single RA connection across a series of
operations -- e.g.

  "svn update a b c" currently opens 3 RA sesssions.

Similarly, inside libsvn_client we often open up an extra RA session
when we could have re-used an old one -- e.g.

  Update with externals -- opens a new session per external [1]

  "svn mergeinfo" -- opens two or three sessions

The attached patch implements "caching" of connections that have been
used and may be used again. The cache is initialized (to empty) by the
caller (the client executable) and connections in it are established or
re-used by libsvn_client as required.

This patch demonstrates the usage inside "svn status" and "svn info"
subcommands, and also (partially) inside svn_client_mergeinfo_log()
which is the guts of the "svn mergeinfo" command.

In this patch, my idea is that the client passes the cache explicitly to
each API (or passes NULL to not use a cache), so that the client retains
control of the lifetime of these connections. The "svn" client, for
example, may not worry about ever clearing the cache whereas a
long-running GUI may clear it after a certain period of time, and/or
limit the number of entries in it.

Thoughts?

In the email threads referenced below, we discussed some related issues
such as whether it would be better to use root-relative paths all the
time instead of "parenting" a session at a specific URL, and how this
ties in with authenticating for access to a specific path. But I don't
think those issues need to be addressed before adding the basic ability
to re-use a session at all.

Prior discussions:

[1] Email thread "Re-use connection for svn:externals", from Phillip
Hellewell on 2010-02-08,
<http://svn.haxx.se/dev/archive-2010-02/0168.shtml>.

[2] Email thread "[RFC] Concept of RA session relative paths", from Ivan
Zhakov on 2009-10-13,
<http://svn.haxx.se/dev/archive-2009-10/0334.shtml>.

- Julian