This is friendlier to the YAML input and consistent with FieldFlags.
Less consistent with the rest of the codebase, but local consistency matters
more IMO.
Next steps:
* A tool to fill the PDF form based on values written to that YAML.
* An extension to fill some of those values with numbers queried from the
books (which is why we need something more involved than FDF).
This is a *very* rough initial draft of a report. As the docstring mentions,
it's basically counting on the user to provide rewrite rules to provide the
desired representation.
Long-term I'm hoping maybe we can standardize the program metadata enough,
or plan its replacement well enough, that this report can be written against
that directly. But that will take more planning about books structure, and
support from the plugin, before the report can be written that way.
Where assertions are removed from individual tests, I believe that
functionality is covered by other tests (although probably not to the extent
of checking multiple splits).
A few motivations for this:
* This makes the fund report more maintainable, because the data structure
is better suited to the task at hand, making it easier to follow what's
going on.
* This helps put Balances through a little more testing with a high-level
report.
* This makes the fund report a little faster, since totals are usually
calculated from a smaller number of Balance objects rather than all
Postings over a period.
The balances reported on the trial balances sheet included an account's
subaccounts. e.g., the balance for Expenses:A would include the balance
for Expenses:A:B. We don't want that traversal for this report, so
inhibit it and report only exact account balances.
This is basically a pure maintainability change: concurrent.futures is the
nicest API that's available in both Python 3.6 and 3.7, and our other tools
are using it.
We're basically always going to have a "packet build step," and it makes
more sense to have the manifest generated there, since it's the thing that
consumes the manifest, rather than here.
This is less "future-proof," but the thing is, it's premature to try
to anticipate what other link formats will be in the future. See
discussion in comments.
