[lmi] Group quotes, part deux

[Greg Chicares]

The original group quote implementation followed the specifications of
its end users. Now they've been replaced by a different group of end
users who want different data in a similar layout, which is to be
released this month with a code-freeze date of the twenty-third. I've
already done much of the work, and know how to make certain footnote
changes that will be necessary, but I seek counsel on a particular
set of deeper changes.

The columns to be shown in the new report depend on context, yet in a
fairly simple way: the set of columns now in HEAD are always generated,
and some (or none) are suppressed. Here, "suppressed" means that a
column doesn't appear on the report whatsoever--printing its title and
blank or all-zero contents below is not enough--and presumably I could
figure out how to accomplish that, but it's more sensible to ask for
advice. I can easily identify which columns to suppress; I'm just not
sure how to prevent them from appearing in the PDF.

The "context" depends on all the data that will appear on the report.
As of 20160505T1120Z HEAD, the code has been slightly restructured to
make that easy. (Recall that data for each cell are generated serially
in a single pass through the census, and fed to
  group_quote_pdf_generator_wx::add_ledger()
as they're created, then destroyed. We aren't writing a group-quote
system from scratch--instead, we're extending an illustration system
to do group quotes--so changing this fundamental logic is out of the
question.) Fortunately, the original group quote gathered and stored
all the data it needs during this serial pass and formatted it later.
Now, we just want to do some extra processing after all data have
been gathered and before they're formatted.

Specifically, this "extra processing" means:
 - deducing a "plan type" string that will be printed (this looks
   pretty complicated in the problem domain, but implementing it is
   trivial, so I won't explain it here);
 - deciding which columns to "suppress"; and
 - showing averages as well as the totals presently shown--I know
   how to calculate them, and could presumably figure out how to
   draw them in the wxPdfDoc device context, but it's more sensible
   to ask for help here.

Here are some concrete questions:

Where should the results of this "extra processing" be stored?
Right now, we have
    global_report_data report_data_;
    std::vector<row_data> rows_;
    totals_data totals_;
aside from which 'group_quote_pdf_generator_wx' has no data members
other than
    page_metrics page_;
    int row_num_;
My inclination is to add a few new data members to that main class,
but it seems best to ask first, because I don't want to pollute the
design through lack of understanding. The global_report_data struct
might be a better place to store these new data, for encapsulation;
OTOH, that struct is now just a collection of strings, all directly
ascertainable from the composite ledger alone, and adding this new
information (which is not ascertainable that way) would change the
nature of the struct. Perhaps this question is too abstract, and I
should just implement something and solicit criticism.

Does it seem beneficial to change the way totals are calculated,
now that we'll need "averages" as well? Right now, we accumulate
totals in a 'totals_data' object by writing
    if(is_composite) {totals_.total(col, z);}
in many 'case' blocks in add_ledger(). Now we'll be post-processing
the reporting dataset anyway (for other reasons), so would it be
cleaner to calculate totals and averages in one post-processing pass
through that dataset?