Package Builder; Split Sources; API Changes

There are kind of a lot of changes here, one thing led to another...

I'm open to feedback on any aspect of this PR

• PackageBuilder for building packages should open up some functionality for building packages.
  • It's sorta a builder pattern, but it takes mutable references to self instead of ownership. I figured it was slightly more ergonomic in the general case since a lot of the use cases are going to iterate something to add packages to the builder.
  • The builder is able to write the head and data segments to different writers, which allows for .pkgar_head and .pkgar_data files. Ofc it is also able to write them to the same writer.
• I split PackageSrc into two traits, PackageHead and PackageData, and included a couple of marker types for building package sources to reduce code duplication.
  • The marker types/traits should allow for a zero runtime cost and correct usage of the API for reading packages, which is always a priority. See PackageBuf for a slightly cleaner implementation of these markers than PackageFile.
  • PackageData does not require mutable access in order to read anymore, due to my revelation that &File implements Read...
  • PackageHead has to store the entries in memory. I did a little math and even a very large package's entries would not take up too much space. It may be worth removing the Copy impl from Entry, because of the 256-byte path field (if stack overflows become a problem...).
  • The Transaction API takes types that implement both PackageHead and PackageData. To get around this, I implemented those traits for (PackageHead, PackageData) so that a tuple could be created at the call site (for example, Transaction::install((head, data), ...)) that satisfies the requirements of the trait bounds without requiring one type. This is in the documentation.
• EntryReader now stores state and duplicates the functionality of ext::copy_and_hash. This cleaned up the transaction code some and hopefully reduces the required mental bandwidth for users of these types.
• The pkgar::binprint module has a hella gross print function that does no verification whatsoever and basically prints out the bytes (and parses+prints ints) in a format that is slightly easier to read. It was useful to me a couple times in debugging, I'm not sure it should necessarily be included in the library, the code is horrible.
• More tests and docs. Always need more/better of these.