- SecKey took a lower-level approach for its 0.11 API, so I refactored
  passwords to include a new type to make sure everything gets zeroed.
- Bunch of documentation work, I'm happy with the state of the rustdoc
  and error handling, at least enough to release 1.0 soon.

Fixed two little bugs:
- Private key files now use 600 instead of 644
- Fixed default key file paths

Pulled in the same error deps as the main library,
- UFE for easy pretty-printing of errors
- thiserror for deriving std::error::Error for error types

pkgar-keys now uses two error types, one that includes a file path for
context and an ErrorKind for passing around internally and containing
other error types. I'm still not happy with the sheer volume of
boilerplate needed to create Error, so more work is needed, but error
reporting is much better with these changes, and is probably more
maintainable even given the boilerplate.

Keys lib

See merge request !6

I'm not super happy with this design because it makes for a reasonable
amount of ugly boilerplate for implementors of PackageSrc. Works though,
and it's faster.

TODO: Implement new type for buffers of u8s instead of impl PackageSrc
for AsRef<[u8]>

Everything appears to be functional. I assumed that two functions that
were called the same thing with approximately the same contents had the
same behavior... not a safe assumption to make. That function is now
reimplemented, among with several other small fixes. I also added a call
to `pkgar list` in the tests to make sure it doesn't panic or do
something else equally dumb.

I also added a dependency on UserFacingError... I'm not sure how much
value it will add, but I can see it being more useful as pkgar matures
and good error reporting becomes more critical. Many improvements on
that front soon I hope.

In terms of the refactoring that happened last commit: There are some
critical issues with implementing PackageSrc as a trait, namely needing
to call read_at (which should be considered expensive) in order to read
the header, something that most of the functions have to do. read_at
could conceiveably cross network boundaries in the future, so it's
important not to call it unessesarily. More design work needs to be done
there.

This compiles, but the tests fail due to an off by one or similar issue
hiding someplace. Debugging is going to require a significant set of
improvements to the error handling in the crate, the messages are crap
atm.

I also added the thiserror crate to make generating error impls easier,
so it should be fairly straightforward from that side of things to
improve the errors. Note that thiserror isn't no_std right now, so it's
only used in pkgar, pkgar_core implements all the froms without the help
of a macro.

- Use --pkey and --skey in both crates.
- Remove single bin target for pkgar; use main.rs
- Clean up mentions of rand in pkgar

pkgar-keys is imported from
https://gitlab.redox-os.org/MggMuggins/pkgar-keys

- Uses pkgar-keys to read and write keyfiles instead of just binary keys.
- I implemented a couple of `From`s for Error, and removed many map_err
  calls around the lib. I'm sure there's plenty I missed.

Note that the integration tests are failing at this point, I'm going
to fix them separately from this branch and merge over.

Libsodium fix

See merge request !5

I clearly never ran the tests...

In addition to running the tests over my code... I updated the test
script to allow debug builds when stuff panics and you need a backtrace,
release builds optimize out the line numbers.

Port to libsodium

See merge request !4

It looks like sodiumoxide only depends on std for serializing with
serde, disabling default features should preserve no-std for the
library.

As I more or less don't know what I'm doing with crypto stuff, there's
probably some bits of code in here that are super naive. Also it hasn't
gone through much testing, so I don't know what the value is there
either.

I'd like to integrate `pkgar-keys` at some point (little project I've
been working on to store keys for packaging and verification), but I'd
appreciate some guidance on how those should be formatted. More
discussion should probably happen in the repo:
https://gitlab.redox-os.org/MggMuggins/pkgar-keys

As noted in blake3 documentation
> To get any performance benefit from multi-threading, the input buffer
size needs to be very large. As a rule of thumb on x86_64, there is no
benefit to multi-threading inputs less than 128 KiB. Other platforms
have different thresholds, and in general you need to benchmark your
specific use case. Where possible, memory mapping an entire input file
is recommended, to take maximum advantage of multi-threading without
needing to tune a specific buffer size. Where memory mapping is not
possible, good multi-threading performance requires doing IO on a
background thread, to avoid sleeping all your worker threads while the
input buffer is (serially) refilled. This is quite complicated compared
to memory mapping.