Add the client side of the backup API.

This builds on the work of Michael Foord.  I've reorganized the code a little, added tests and factored out the raw RPC code from the backup client code.  (The raw RPC can later be re-used by the other 2 client methods that currently duplicate the code.)
If I'm reading this correctly, there is a subtle but major difference in how we are computing the hash. The MultiWrite version would be computing the hash on the *uncompressed* content, rather than the gzip stream.
I have the feeling that was intentional.
(It also had the nice property that you could do one pass over the data, rather than writing it all out, and then reading it all back in again to compute the hash.)
Regardless, while we probably do want a helper for computing the hash, we need to decide if it is of the final compressed bytes, or of the content inside the tarball.
It is certainly easier to verify just the compressed bytes, but the hash of the flat content means it doesn't care whether you used gzip or bz2, or xz, or seeded your gzip with a different date, etc.

I'm open minded, but changing something like this should certainly be part of the major decision, and not just a side effect of the patch.