It gets in the way of Eliot logging.

If SpendingController develops some internal state it should really remain
internal, anyway.  Don't make _plugin.py worry about this.

just bumping CI really

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.

Along with an in-memory implementation of a pass factory that works with it.

`assertThat` and `succeeded` can do the job *most* of the time.

If all passes were good but there simply were not enough of them, don't retry.

Replace the tricky _rref property with a decorator.  This guarantees _get_rref
is evaluated for each function call before we do anything with pass generation.

Same logic should apply to the rest of the pass-spending methods.

Then, logic can be extended to cover retry for other failures and putting
passes back in the database for non-spending failures and converged uploads.

Meant this to be in PR#152 but somehow forgot to even commit it...

Also centralize the exception-raising in one place