clear the cache after last transaction completes, even on exception

The cache must not remain populated just because the usual "clear the
cache" logic is bypassed by exceptional flow control.  The cache must
always be cleared when the topmost transaction is completed, even if
"completed" means "dies."

** PLEASE NOTE **

It is important that no transaction ever catch an exception thrown by
a nested transaction, then attempt to continue operating as normal.
The nested transaction may have left objects in an inconsistent state
that must not be written out to storage.

For example:

  do_rw(sub {
    try {
      do_rw(sub {
        $ledger->update_that_works;
        $ledger->update_that_dies;
      });
    } catch {
      warn "oh no! <<$_>>";
    };

    $ledger->some_other_stuff;
  });

Here, the outer transaction will still continue after the fatal error
thrown inside the nested transaction.  The changes made in
"update_that_works" will be written, even though they *must not be*
without the other related changes.

If a transaction dies, any objects handled by it must be thrown away
and not considered valid for inspecting, changing, or saving.
Add consistency check to Spike->_cache_ledger
Ob should always get ledgers straight from the database

It now bypasses the in-memory cache.
Merge branch 'xact-bug-massacre'
let refundable credits track pay info
do not allow unknown consumer data

I was losing data because it was being ignored!
fix the creation of import credits

including making the ->active_consumers ledger method
basically *work*
test that imported credit works
avoid an annoying @{undef} case
amend POST-created ledgers to get them cached

...otherwise this happens:

  my $ledger = class('Ledger')->new(...);
  $ledger->add_some_consumers_which_charge;
  $ledger->perform_dunning;

Dunning ends up looking for $invoice_charge->owner.  InvoiceCharge
objects don't have a ref to their owner or ledger.  They have guids.  So
to get the owner, they do:

  sub InvoiceCharge::ledger {
    Storage->retrieve_ledger_by_guid( $self->ledger_guid);
  }

  sub InvoiceCharge::owner {
    $self->ledger->consumer_by_guid( $self->owner_guid );
  }

During initial creation of ledgers via PostTarget, though, the ledger
wasn't in the cache, so the retrieve call looked in the db, didn't find
it, and chaos broke look: we tried to call a method on undef, because
the call to $self->ledger, above, returns undef.  (I'll add a sanity
check for that.)

So, anyway, the solution is to cache the ledger as soon as possible once
it is instantiated.
assert that we can retrieve an InvoiceCharge's owner
forbid supersession of active or expired consumer
extract method Consumer->charge_current_journal
extract method Consumer->charge_invoice
remove obsolete Consumer->build_charge method
no ByTime::estimated_lifetime for active consumers

This could lead to confusion with the expiration_date method, which
computes the same question (how long will I live?) with a different
means.  We should find all these kinds of methods and rationalize them.
expiration date on FixedExpiration should be fixed: ro
expire_date is now expiration_date

This resolves some disagreements on name, but changes more than it
keeps -- but "expiration_date" is more likely to be a first guess
than "expire_date," which... well, who says that?
create a role for "can predict death"
make ByTime do PredictsExpiration