Dead return to silence g++ uninitialized warning
Print cmd arg defaults; skip pg output if disabled
Demand belief updating was broken: also got Q_d=0.

The update needs to happen with the sales for t-1, not t, since
interopt optimizers run with t set for the upcoming period, but
updating needs to reflect the previous period sales.
Minor comment update
upperBounds()[i] -> upperBound(i) etc.

The subscripting and extra proxy object was pointless verbose.

This also adds const versions of upperBound() and lowerBound() so that
querying (i.e. restricted() and operator double()) can be done on a
const LinearRestricted.

The actual code for restricted() and operator double() is now moved
into Linear (hasRestriction() and getRestriction()), with the proxy
object simply calling those methods.
Added restrict() proxy object; and use it.

restrict(j) works sort of like upperBound(j) and lowerBound(j), except
it allows specifying either restriction using the rather nice syntax:

    object.restrict(j) <= upperbound;
    object.restrict(j) >= lowerbound;

which I find more intuitive code than using `upperBound(j) = ...;`
Clear s2, V values for non-existent beliefs

Previously they weren't updated, which means moving forward (to a
period where profit beliefs exist) then back again left the last viewed
s2 and V matrix values.  They are now cleared.
Comment grammar fix + reflowing
update() and weaken() via B instead of Linear

The base class may have some override, so it seems more correct to call
B::update() and B::weaken() instead of Linear::update() and
Linear::weaken().

Currently only Linear and LinearRestricted are being used as bases, and
so this makes no difference (because LinearRestricted doesn't override
them), but this is more correct.
Just predict(), don't need explicit base method

Quality doesn't override predict(RowVectorXd), so there's no point in
being explicit about the Linear method.
Doc updates for previous LinearRestricted changes

Updated obsolete restriction example code with new version of code.
Use stock noninf prior

The custom noninformative prior here didn't make much sense anyway: why
should next period profits equal previous period profits?
Remove obsolete comment
Various learning fixes

- Profit, profit extrap, and profit stream beliefs now all track
  user-perceived profit (that is, profit at the believer's costs, which
  might be different than the author's costs).  Previously this was a
  mix of revenue and profits, and as such was probably wrong.
- Don't attempt to learn profit stream info from pirated copies of
  off-market books: they aren't necessarily applicable to the current
  world (in particular, they should have been incorporated many weakened
  iterations ago, but that doesn't seem easily feasible.  (Although it
  might be: the current belief could be *strengthened*, the row
  incorporated, then weakened again).
- Profit expectations should come from extrapolated profit, since
  that's where the effort choice came from.