Support SDMF in the `download` API

Closes #8

See merge request !5

new versions of both required for fixes involving incompatible API changes

This is clunky but it works ... for now.

Also add SDMF instances for them and tweak the tests to work with the new
tahoe-ssk encode interface.

* check as many servers as necessary/possible for encoding parameters, instead
  of just the first
* add cap class instances for SDMF capability types
* teach the decoder about SDMF

Cleanup immutable factoring

See merge request !4

Slightly simplify some of the download implementation

See merge request !3

`cabal run tests` sometimes fails with an error about the build plan not
including the test suite :(  but we can make sure the plan includes the test
suite with this flag.

Basically, move more processing inside the `Either DownloadError` so that
context can be disregarded where it isn't relevant.

Also remove the list from `downloadShare` so that its caller can arrange for
any desired concurrency, retries, etc.

Incorporate tahoe-great-black-swamp to do share downloads using GBS

Closes #2

See merge request !2

StorageServer hides all of the networking details in the real implementation.
If tahoe-great-black-swamp works then the existing success case should
exercise all of the same logic in gbs-downloader whether we're actually using
it or not...

It might be nice to move all of the StorageServer implementations into
gbs-downloader and then test that they really do behave the same as each
other. Right now they're mostly in tahoe-chk though so that's annoying.

a bit, anyway

fixes for base64 issues

Try as hard as we can to make ``download`` return its failures in a Left
instead.

Also factor most of the tahoe-great-black-swamp parts out of `makeServer`in to
a separate helper function.  I thought this function might be where the
exception handling goes but it can't really yet because StorageServer requires
IO exceptions as part of its interface.  Should likely fix that sometime.