Fold abs where the sign of its argument is known (#881)

[Rafael-SOWNet]

Closes #881.

|x| is x for a non-negative real x and -x for a negative one. That is the definition of
the function, not an identity carrying a side condition — but it was applied only where the argument
was a Number node. An argument whose value is a known real, without its node being a number,
was left alone:

	was	is
abs(-sqrt(6))	left as written	sqrt(6)
abs(-pi), abs(-e)	left as written	pi, e
abs(1 - sqrt(2))	left as written	sqrt(2) - 1
abs(-2)	2	2, unchanged
abs(sqrt(-4))	2	2, unchanged — the magnitude of 2i
abs(-a) for symbolic a	left as written	left as written

Where it is visible is in an answer built out of radicals. (2x^2 - 3 > 0) and (x > 0) solved to
(abs(-sqrt(6)) / 2; +oo) and now solves to (sqrt(6) / 2; +oo). The endpoint was always the same
number, printed in a form that reads as unfinished work.

What is not assumed

The sign is read off Evaled, which means the rule declines rather than guesses in the two cases
where guessing would be wrong:

• A symbol has no sign. abs(-a) stays as written. Nothing here assumes a is real, let alone
  which side of zero it is on.
• Off the real line there is no answer of this shape. sqrt(-4) evaluates to 2i, whose
  absolute value is 2 — neither the argument nor its negation. A rule reading "the value is
  negative, so negate it" would be wrong there, so a value that is not a finite real does not fire
  it.

The half that is not here, and why

#881 also asks for |-x| = |x| for a symbolic x. That is unconditionally sound — negation is
an isometry — and it is the example SimplificationContract.md uses for an empty assumption set. It
is not in this PR, and the reason is measured rather than guessed:

simplify(sgn(-a))               => sgn(-a)          // no odd-symmetry normalisation
simplify(sgn(-a) * abs(-a))     => -a               // this works today
simplify(abs(-a) + abs(a))      => abs(-a) + abs(a) // this is what the rewrite would buy

Rewriting abs(-a) to abs(a) on its own breaks the middle line: the pairing rule wants
sgn(t) * abs(t) for the same t, and sgn(-a) does not normalise to -sgn(a). So the even
symmetry of abs wants the odd symmetry of sgn alongside it, as one change with the collection of
abs(-a) + abs(a) to show for it. Trading a working answer for a new one is not a fix, so it is left
to be done properly.

Measured

Suite 6320 passed / 0 failed, including 10 new cases in SimplificationRegressionTest. casbench
117/119 with 0 wrong, rootcheck 596/596, simpsweep 10463/10463, propcheck 0 failures, crashcheck
1652 cases with 0 crashes.

boundcheck needed four builds to read honestly, so here they all are:

build	shapes rewritten	disagreements
master d8bfcd51	46	6
master + this branch	46	6
master + #899	44	4
master + #899 + this branch	44	4

This change adds no disagreement in either context. The middle two rows are the interesting
part, and they correct something the commit message on this branch gets wrong: it says the report
checked in alongside the harness was stale, and it was not. It says four because it was generated
on a build that already carried #899, which removes exactly the two entries master still has —
abs(sgn(x)) and sgn(abs(x)), each simplifying to 1 where both are 0 at x = 0. Those are
#892, already fixed in #899, and not
something this branch discovered or needs to file.

These two PRs conflict, and they do compose

#899 replaces the two arms immediately above the one added here, so git reports a conflict in
Evaluation.Continuous.Arithmetics.Classes.cs, in SimplificationRegressionTest.cs, and in
BREAKING-CHANGES.md — all three are adjacent additions rather than disagreements. Merged together
on a throwaway branch and measured: 6342 tests passed / 0 failed, and the four boundcheck
disagreements above. abs(-sqrt(6)) still folds to sqrt(6), abs(sgn(x)) is still left alone, and
abs(sgn(0)) is still 0.

Resolution order matters and is worth stating for whoever merges second: #899's
Signumf(var signOf) when ValueWithCondition(...) arm goes before the var argument when argument.Evaled is Real ... arm from this branch. The latter is a catch-all with a guard, so put it
last. A C# switch takes the first arm that matches, so with it first the abs(sgn(2)) case would
reach the catch-all and hand back its argument sgn(2) — the same number, one reduction step short
of what #899's arm gives it. The merge I measured has them in the order above.

One follow-up on release

The Solvers wiki page prints the old
(abs(-sqrt(6)) / 2; +oo), and docsamples reports it as its single output mismatch. The page
should be updated when this ships, not before — until then it correctly describes 2.0.0.