we'll also run the tests after which is great, but this at least gets us some
automatic checking of our executables which aren't really covered by automated
tests

callers of the encode interface are now required to pass in the correct iv for
the ciphertext being encoded

Parse and serialize SDMF capabilities

Closes #1

See merge request !8

Remove all of the GitLab cache configuration

See merge request !9

The cache periodically becomes corrupt and causes builds to fail.

Plus various basic instances (Eq, Show, mainly) to make testing this piece
easier.

Also some more Hedgehog generators for types related to capabilities.

Also scatter some more Eq and Show instances around to make this possible.
Also change some Show instances to elide most of the content of secrets.

Implement enough encryption and encoding to be able to read plaintext from Tahoe-LAFS-generated SDMF shares

Closes #5

See merge request !7

This functionality moved in to readShareFromBucket

We need a lot of type conversions and we'd like to be more principled than
`fromIntegral`.

We use `isolate` so we know exactly how far we've advanced, we can trivially
compute the correct position.

instead of confusing it with the segment length sometimes, which includes
padding bytes

The trick is that we don't use the IV to initialize CTR mode, we only use it
to derive the data encryption key and then use the zero IV to initialize CTR
mode.  (So is it an IV?  Not really I guess.)

The failure is due to incorrect handling of padding somewhere so we get extra
bytes on the recovered ciphertext/plaintext.

It doesn't have an assert but it prints the wrong output

Add simple SDMF capability representation

See merge request !6

Add a Keys module with types and derivation functions

Closes #6

See merge request !5