They're all redundant on Python 3

avoids ambiguities and implementation problems of iso8601 duration strings

go back to aniso8601 dependency, since we no longer get anything distinctive
from isodate

It is observed for each redemption group and it could vary for groups
belonging to a single voucher.

Take care not to spend them, though.

removing the operation-id may not actually be an improvement ... it is a
simplification, though.  However it requires us to load all the rows into
python and then send them back to the database instead of only loading them.
I thought removing the operation-id from the in-use table would be a win and
maybe it is but not for the reason I thought - sqlite3 emits the same code
whether you do `in [foo]` or `in (select x from [foo])` as far as I can tell.

Still, I like the simplification so we'll go with it for now.

Instead of immediately extracting passes, get them and later mark up the store
with the outcome of the attempt to use them.

Parens can create a tuple or something and we don't want that.

This removes almost all uses of the global value.  All that remains is its use
as a default in case no configuration is given.

This makes the database responsible for remembering how many tokens we expect
to get for a voucher, rather than the in-memory Python state or the code.

As a result, we can resume redemption knowing the correct number of tokens
after a process restart and without relying on the PaymentController's default
token count to have remained unchanged.

Redeem the voucher once for each redemption group.
Track progress in the database.
Delay entering the "redeemed" state until all groups have succeeded.

Allow voucher additions that are only distinct on the counter value.