Give floor and ceil a limit case, and answer the floor of an infinity (#829, #830)

[Rafael-SOWNet]

Closes #829. Closes #830.

Two defects introduced by #827, in the order they have to be fixed: the second commit's answer at the
infinities depends on the first.

#830 — floor(+oo) threw OverflowException

The Real branch of evaluation converts through EInteger, which refuses the infinities and NaN,
and the exception reached the caller. An internal PeterO.Numbers fault is not one a caller of
Evaled has any reason to expect, and the neighbours do not raise it — abs(+oo) is +oo and
abs(0/0) is NaN.

An infinity is its own floor and its own ceil: there is no greatest integer below +oo. NaN
propagates. Both are exact, so the new branch sits ahead of the !isExact guard and Simplify
answers them too.

eval(floor(+oo))   OverflowException -> +oo
eval(ceil(-oo))    OverflowException -> -oo
eval(floor(0/0))   OverflowException -> NaN

#829 — a limit over floor or ceil killed the process

Neither node overrode ComputeLimitDivideEtImpera, so both took the base implementation, which
returns an unevaluated limit of the very node being asked about. The two-sided path compares its
one-sided results by evaluating them, evaluating a limit computes it, and control arrives back at the
same node. It is a stack overflow, so it is not an exception a caller can catch.

This is #704 on a new pair of nodes. The Signumf override written for that issue carries a comment
saying exactly this, and Modf's says it again for its own jumps; this adds the third case rather
than a third copy of the reasoning.

Away from its jumps a step function is locally constant, so the limit is the function of the
argument's limit. On a jump the two sides disagree, and which side the argument arrives from is not
decided by the side x approaches its destination from — lim(x -> 0+) floor(2 - x^2) reaches 2 from
below and lim(x -> 0+) floor(2 + x^2) from above, and both are limits from the right. So a jump is
declined with null, which hands the caller an unevaluated limit, and no value is invented for it.

lim(x -> 0)   floor(x)   *** stack overflow *** -> limit(floor(x), x, 0)
lim(x -> 2)   floor(x)   *** stack overflow *** -> limit(floor(x), x, 2)
lim(x -> 1/2) floor(x)   *** stack overflow *** -> 0
lim(x -> +oo) floor(x)   *** stack overflow *** -> +oo
lim(x -> -oo) ceil(x)    *** stack overflow *** -> -oo

The imaginary part is only checked for a genuinely complex limit: a real value's imaginary part is
identically zero rather than tending to zero, and the floor of a constant zero is constant. Like the
Absf and Signumf overrides beside it, this reads the argument as real-valued along the path;
narrowing that wants a way to decide realness the library does not have yet (#721), and it is written
into the remarks rather than assumed silently.

Declining is conservative in a couple of places where an answer exists — lim(x -> 0) floor(cos(x))
is 0 on a punctured neighbourhood and comes back unevaluated, because cos reaches the integer 1.
Unevaluated is honest there; inventing one of the two one-sided values would not be.

Measured

C# suite	5903 passed, 0 failed, 14 skipped
F# suite	130 passed
casbench	113/117 solved, 0 wrong, 0 error, 0 timeout — unchanged
rootcheck	596/596 clean
simpsweep	10463/10463 agree
propcheck	1340 checks, 0 failures

Worth doing next, and not in this PR

Neither of these is a mathematics mistake — #827 wired the node, evaluation, ToString, Latexise,
ToSympy, differentiation, InvertNode, Substitute, Sort, Domains, the grammar and a full test
class, and missed one file. Nothing in the repository lists where a new Entity subtype has to be
wired, so there was nothing to check against.

A test generated by reflection over every Function subtype, asserting that a limit of it terminates,
would have caught #829 before merge. round, trunc, min, max and the rest of #809 hit the same
trap.