++ and -- skip the addition rounding rule: 1.2E3++ gives 1201, while 1.2E3 + 1 gives 1200 #125

What's wrong

Increment and Decrement (SignificantNumber/SignificantNumber.cs:283-292) call PreciseNumber.Increment and PreciseNumber.Decrement directly:

public static SignificantNumber Increment(SignificantNumber value) =>
	new(PreciseNumber.Increment(value.Value));

Add and Subtract treat 1 as an exact operand and round the result to the other operand's decimal place (LowestDecimalDigits). ++ and -- never do that rounding. As a result, x++ and x + SignificantNumber.One can disagree, and so can generic math code that uses T.Increment or v++ on a SignificantNumber.

Failure scenario

At HEAD a15223e:

Parse("1.2E3")++      = 1201   (expected 1200)
Parse("1.2E3") + 1    = 1200
Parse("1.2E3")--      = 1199   (expected 1200)
generic Inc<T>(1.2E3) = 1201

The value 1.2E3 is only known to the hundreds place, so a result of 1201 reports precision the inputs don't have. That is exactly what the #107 rule exists to prevent. Values that are already at the units place or finer (0.5++ == 1.5) are unaffected.

Suggested fix

public static SignificantNumber Increment(SignificantNumber value) => Add(value.Value, PreciseNumber.One);
public static SignificantNumber Decrement(SignificantNumber value) => Subtract(value.Value, PreciseNumber.One);

(Use whatever the internal Add/Subtract helpers' signatures are.) Note that the separate integer-addition regression from #119 (10 + 2 == 10) would then also apply to 10++, so this should land together with, or after, the fix for that regression.

Acceptance criteria

• x++ equals x + One and x-- equals x - One for every x, covering both a coarse value (1.2E3) and a fine one (0.5).
• There is a generic-math test that calls T.Increment / T.Decrement on SignificantNumber.