[lmi] Supplemental report with zero-percent columns

[Greg Chicares]

Prior to the change committed 20090926T0137Z:

  alt-F N I
  OK

  alt-F F
  select 'PolicyFee_Current'
  OK

elicited a messagebox complaining:

  "map_lookup: key 'PolicyFee_Current' not found."

That change fixed that particular problem, but introduced
another, reproducible thus in HEAD as of this moment:

  alt-F F
  select 'AVGenAcct_CurrentZero'
  OK

  alt-F N I
  select any general-account-only policy form
  OK

elicits a messagebox complaining:

  "No values for basis 'curr charges and genacct int, zero sepacct int'"

The patch below [0] is a stopgap that restricts these columns:
  '*_CurrentZero'
  '*_GuaranteedZero'
to supplemental reports created with a home-office password; for
general-account-only policy forms, those columns, if selected,
show all blanks. That's not ideal, but it prevents the severest
problems.

It seems plain now that adding these columns to the GUI was a
mistake. The objective is just to provide a supplemental report,
when general- and separate-account balances are both nonzero,
with a particular set of columns on these bases:
  "curr charges and genacct int, zero sepacct int"
  "guar charges and genacct int, zero sepacct int"
Adding columns on those bases to the GUI creates problems for
non-variable policy forms, for which those bases are undefined.
Except to comply with a regulatory requirement, no end user would
ever wish to use any such column in a supplemental report.

Because the desired supplemental report contains a particular
fixed set of columns, it would seem better to implement it in the
appropriate '.xsl' file, as was done in this 'nasd.xsl' template:
  <xsl:template name="supplemental-illustration-report">
That's easier for end users and less prone to manual error. This
special hard-coded supplemental report should appear if and only
if a particular condition is met. I'm not exactly sure what that
condition is, but it might be either (or both) of these:
 (a) 'GenAcctAllocation' is neither one nor zero; or
 (b) 'AVGenAcct' and 'AVSepAcct' are both nonzero.
(a) is fairly straightforward because it uses only a scalar.
(b) is harder (in xslt) because it involves two vectors.