OUT/OOParsing: shouldn't matter, but just in case...

always re-optimize when optimize become()s

Signed-off-by: Gregory M. Turner <gmt@be-evil.net>
OUT/RulesParser: naming consistency: ...

BooleanNegationProduction -> NegationProduction

Signed-off-by: Gregory M. Turner <gmt@be-evil.net>
OUT/RulesParser.py: BooleanProduction: don't sequence-flatten

Sequence flattening will become too strong an optimization for
BooleanProductions once we start using it as a base-class;
therefore, use ephemerization to flatten only cases where
a BooleanProduction (not a subclass) is the direct child of
another BooleanProduction (not a subclass).

Document the meaning of BooleanProductions as order-of-operations
placeholders explicitly.

Signed-off-by: Gregory M. Turner <gmt@be-evil.net>
OUT/RulesParser: {Con,Dis}junctionProduction

Add a new base class for ConjunctionProductions
and DisjunctionProductions, and use it to implement
the parsed conjunctions and disjunctions; drop the
old gobbldey-gook optimization code, which read like
an undocumented SHA256 implementation, and refactor
into the object framework.
OUT/RulesPaser: NegationProduction: optimize BooleanProductions

Now that BooleanProductions are no longer sequence-flattening
it's possible to get a NegationProduction of a BooleanProduction
which contains a single NegatableBooleanProduction only.

In this case, negate the inner NegatableBooleanProduction and become
the BooleanProduction (so as to preserve the precedence information
signified by the BooleanProduction).

Signed-off-by: Gregory M. Turner <gmt@be-evil.net>
OUT/RulesParser: todo comment

Signed-off-by: Gregory M. Turner <gmt@be-evil.net>