OutputParams refactoring

[Yuriy Skalko]

> Yes, I looked at it but didn't have time then to comment.
> 
> It's fine as far as it goes, but I was thinking something somewhat different. Others can chime in, perhaps, but I think there's a reason that OutputParams was always supposed to be passed as const. At least, it began life as precisely what it sounds like: A bunch of parameters that give us information about what we're supposed to output. These, one might imagine, would be set once and for all when the output routines we launched.
> 
> 
> But then, I think, OutputParams grew into a somewhat different beast: A collection of flags that affect output and that can be set and reset during the output process. In a way, that's not so difficult: We can copy the OutputParams to some temporary object, change them as needed, and pass the temporary down the chain. This gets done quite a lot, in fact. But then it gets worse: Sometimes, the lower down routines make their own changes, which need to be propogated *back up* the chain. So now the temporary object solution doesn't really work.
> 
> 
> So, one option, indeed, is to forego the pretense that OutputParams is const and just pass a reference everywhere. That's what your patch does. The other, which is what I was trying to do some time ago, is to untangle this mess, especially the back-propogation of flags from the lower down subroutines. Making all those things mutable was a hack-ish solution.
> 
> 
> A start on fixing this would be to figure out which things really do need to be back-propogated and which things don't, and make only the former mutable, and force changes to the latter to be done with a temporary object. Whether it's all worth doing isn't entirely clear to me.
> 
> 
> Riki

Maybe split OutputParams into 2 parts: class with output parameters that 
are not changed on document tree traverse (OutputParams, passes always 
as const reference) and class with current output state, varied during 
traverse (OutputContext, passed always as reference)?

And to implement for OutputContext the push/pop operations (with 
internal stack) to save/restore parent context (when needed to do local 
changes) or directly modify parent context if changes should be 
propagated on the higher level.

Does it make sense?

Yuriy