Transactions

It's been several months since I wrote most of this code, so I don't remember quite everything that I was thinking at the time. Still, here's a write-up:

• Transaction API: In order to maintain semi-atomic install/replace/remove operations, the package needs to be unpacked to a set of temp files and then those files moved into their final locations. The transaction API in the MR allows a user of the library to create a Transaction, which encapsulates this list of temporary files, and allows users to do something between creating the temp files and calling commit or abort. I also rewrote the high-level functions from crate::bin to use this API.
• Error handling overhaul: One of the biggest problems with error handling is the amount of paths that pkgar has to handle. std::io::Error doesn't include path context, but I figured that having path context for pretty much every possible error would be helpful for both debugging and use of the tool. I styled the error type for the crate after std::io::Error, which has a private Repr enum to manage context, and an ErrorKind for the specific error information. One can now call .path, .entry or .reason on crate::Error to add that context to the error. This still isn't entirely ideal, since it's not always clear if context has already been added (pkgar_keys::Error already includes path context, for example), and it tends to encourage lots of map_err(|e| Error::from(e).path(&path) ) everywhere, which isn't super pretty. Suggestions welcome for this.
• There are a couple of other smaller API things like EntryReader for easily reading a given entry and PackageSrcExt to provide a couple other convenient functions that require std.
• PackageFile is also now backed by a BufReader to (theoretically) improve performance, since PackageSrc uses an awful lot of read calls in order to get all the stuff that it needs.

I still view this as a bit of a WIP, so let me know if there's anything I should change or improve. I'm also planning to tackle creating packages as well (my hope is to allow for several different ways to build a package... I've railed against fakeroots in other places 😄.