Handle `runReq` exceptions so they don't blow up the page

See merge request !15

Skip prerendering the two I/O demo widgets

See merge request !14

Unfortunately it looks like `performEvent` is not careful about what happens
to IO exceptions in the action it runs.  We should probably make a safe
wrapper for us to use, always?  Meanwhile, here's a narrowly-scoped fix that
makes the network widget safe against such errors.

When they are prerendered there is a warning about "hydration failure".  This
indicates the DOM prerendered (on the server) somehow doesn't match the DOM
rendered (in the client).  Since it's not obvious what these differences might
be, this might be a hydration bug.  It's just as correct to skip the
prerendering for these two cases though (and maybe we should skip it for
_everything_?)

Demonstrate doing network I/O in the app

See merge request !13

The Date header is weirdly cached by the server and makes it hard to interpret
the behavior of the app.  The Age header is simple and predicable.

Replace `LANGUAGE CPP` with two platform-specific source files

See merge request !12

Fix a few warts in the frontend code

See merge request !11

`LANGUAGE CPP` works but comes with some downsides (surprising source
rewriting, more recompilations).  We can avoid them by having cabal deal with
the platform differences instead.

Call an API from tahoe-chk as a demonstration that we can

Closes #13

See merge request !9

Also the comment referenced in the comment no longer exists, so stop
referencing it.

In particular, try to give it a factoring that might be maintainable in
practice.

Also, take plaintext from a text input area instead of hard-coding it.

Also switches to the original zfec library version of tahoe-chk since the
Botan version still won't build for Android.

Depend on android-activity and use its `getFilesDir`

Closes #19

See merge request !10

Now that the botan2 derivation is fixed we don't need this.

Also, skip the tests because they're crashing right now. :/

Co-authored-by: Florian <florian@leastauthority.com>

It doesn't seem like it should be necessary but it helps, a little, I think.

It's not clear to me why passing `buildPackages.python3` as the value for
`python` to the `override` call isn't the way to do this.  If we take that
approach then the configure phase fails because it cannot find "python".