Use the database as the location for SVN certificate acceptance storage.

Our cert model for Subversion worked such that when the user confirmed a
cert before adding a repository, we would tell Subversion to go ahead
and save that cert to the local ~/.subversion/auth. If the cert file
wasn't there, file fetches would fail. This made it quite annoying to
have a multi-server deployment, as that directory would have to be
shared.

Now, upon acceptance of the cert, we store the cert information in the
repository's extra_data field. We then look it up from there if pysvn
tells us it needs verification again on a cert.

We still save on the filesystem as well, which is more convenient, but
we're far more resilient now. We can work multi-server, and we can
easily nuke the auth directory, without affecting file fetches.

We also still generate the Subversion config files to configure rbssh
usage for Local Sites, but these are already resilient enough by
themselves, as they're just recreated as needed. So now, Subversion
should work perfectly fine without having to have a permanent
.subversion directory.

Started by turning off automatic trusting of default CAs, requiring
every single cert to be manually verified.

Configured an HTTPS repository without this patch. Verified the cert
file in the .subversion directory. Nuked that cert, and then tried
accessing a diff. Saw the cert verification failure errors.

Then applied this patch and re-saved the repository. Saw the cert file
and the cert info in the database. Accessed the files without problems.

Deleted the cert file, but kept the info in the database. Cleared the
cache. Re-accessed the file. It worked fine. Saw that SVN took the
in-database cert and re-saved it in the .subversion/auth directory.

Repeated another time just to be sure.