Also, explode the tuple that made its way into `redeemVoucherHelper`

`redeemVoucher' reads stuff from the db, makes decisions and then
writes to the db. However if there is another client doing a
simultaneous `redeemVoucher' for the same `voucher', then both of them
would redeem the voucher, which is incorrect. The operations should
have exclusive access to the db and this is achieved with
`withExclusiveTransaction`.

Vouchers table contain all paid vouchers, so to find if a given
voucher is unpaid, all we need to do is check membership in the
`vouchers' table.

Type class instances for `redeemVoucher` function has a lot of
code duplication. This change refactors them to reuse the main
logic of the code and abstract out parts that differ between
instances.

A few cosmetic changes.

Rename the `Memory' constructor that constructs MemoryVoucherDatabase
into `MemoryDB' to avoid conflict.

Also expose all functions for now, for testing via "stack ghci".

Use this function to check if the given voucher is unpaid. Perhaps
this can be done in Sql itself without resorting to set operations.

Also change a Maybe to an Either so we can stop printing an error inside the
ristretto code and just propagate it up to the caller.

None of the FFI values escape from `ristretto` so all of the FFI IO should be
safe to do with `unsafePerformIO`.

It's total amateur hour but that's what I am so who is surprised?