[lmi] A rounding-rule anomaly

[Greg Chicares]

Edit 'sample.rounding' in the GUI. Set all rounding rules to:
  three decimals, nearest
Save the file; close the window.

Now reopen it. The last five rules appear to have changed.

It's worse than it seems. For the 7702 interest rate, e.g.:
  (A) three decimals, nearest       is what you think you saved
  (B) three decimals, upward        is what's used in calculations
  (C) [zero decimals] no rounding   is what the product editor shows

(A) The last five rounding rules are not saved (see the xml).

(B) The explicit ctor
  rounding_rules::rounding_rules(std::string const& filename)
manufactures the last five rounding rules. The 7702 interest rate,
for example, uses the general interest-rate rule, but changes the
rounding direction to 'upward'. See paragraph 7/7 here:
  http://www.nongnu.org/lmi/7702.html
| It is critical that the result be rounded up if at all,
| and never rounded down or truncated.
It's nice to express a requirement like that in the program, but
an error message would be better than an invisible forced change
along a single path of execution.

(C) The product editor doesn't call the ctor in (B); it invokes
Read() on a default-constructed object. This can never have been
tested: it's always behaved this way, and none of this year's
changes have affected it.

I think that if I change the (A) and (B) behaviors in class
rounding_rules, that'll probably fix (C).