The previous keys were not serialized as x509 Private-Key Info structures
which is the format Tahoe-LAFS expects us to operate on.

Standardize on cryptonite

See merge request !4

The test suite fails, though.

This is probably better than pulling in three different crypto libraries for
each of the difference pieces we need.  It's certainly simpler to figure out
how to make the pieces play nicely together since we avoid having multiple
kinds of AES128 key defined, multiple types named IV and PublicKey, and even
multiple implementations of the same module.

Add a Binary instance to deserialize from and serialize to the canonical byte representation

Closes #4

See merge request !3

Specifically, this will build our new `make-keypairs` executable.

Add a representation of the share data

See merge request !2

Read Tahoe-LAFS-generated bytes, decode into a Share, re-encoded to the same
bytes.

Just a round-trip-through Binary test for now

* We can always interpret the IV so represent it using the IV type instead of
  as bytes.

* We cannot interpret the private key without its decryption key so represent
  its encrypted form as bytes.

Take tahoe-chk as a dependency because it can already represent some of the
fields of an SDMF share.  Also, a crypto library for key representations.

Fix a typo in the cabal file that passed with only a warning before.

Configuration for CI

See merge request !1