We now do data filtering/massage as late as possible, not just once at
startup. This should work better for multiple commands, as with web or ui.
The basic benchmark seems at least as good as before thanks to laziness.
With this change, Transactions and Postings reference each other
co-recursively. This makes constructing them more tedious, but it
may also allow LedgerPostings to be dropped and code to be simplified.
Time and space performance of register and balance is as before.
This renames RawTransaction -> Posting and Entry -> LedgerTransaction,
plus a bunch more cleanups for consistency. So while ledger 3 has
transactions containing postings, and so do we when speaking to users,
internally we call ledger 3's transactions LedgerTransaction, and we keep
our old Transaction type as well, because it's useful and used all over
the place. To review:
- ledger 2 had Entrys containing Transactions.
- hledger 0.4 had Entrys containing RawTransactions, and Transactions
which are a RawTransaction with its parent Entry's info added.
Transactions are what we most work with when reporting and are
ubiquitous in the code and docs.
- ledger 3 has Transactions containing Postings.
- hledger 0.5 now has LedgerTransactions containing Postings, with
Transactions kept as before (a Posting plus it's parent's info). These
could be named PartialTransactions or TransactionPostings, but it gets
too verbose and obscure for devs and users.
