WP 34S and 31S bugs and fixes

[Bit]

Thank you, Marcus.

Another issue: The documentation says that the algorithm that PRIME? uses is believed to work up to 9e18, which is roughly 2⁶³, the limit above which the isPrime() function fails with a domain error.

However, because of integer overflows, this is what actually happens (in double precision mode and only considering the integer part of a number):
- Negative numbers are reported as not primes. But odd negative numbers whose absolute value has bit 63 set also produce a domain error. Compare -2⁶⁴+1 and -2⁶⁴-1.
- Between 0 and 2⁶³: The algorithm in isPrime() is applied, errors are not produced.
- Even numbers above 2⁶³ with bit 63 set: Reported as not primes, see e.g. 2⁶³+2.
- Odd numbers above 2⁶³ with bit 63 set: A domain error is produced and PRIME? returns true, try 2⁶³+1.
- Above 2⁶³ if bit 63 is not set: PRIME? returns the result of the input modulo 2⁶⁴, so for example the even number 2⁶⁴+2 is reported as a prime.

I've committed a patch that results in the following more consistent behavior:
- All negative numbers are reported as not primes and errors are never produced.
- The original algorithm in isPrime() is applied to numbers between 0 and 2⁶³-1 and errors are never produced.
- Numbers greater than or equal to 2⁶³ always produce an error and PRIME? returns true.
(The handling of the two infinities and NaNs didn't change: They're always reported as not primes and no error is produced.)

I think it makes sense to treat the same way all numbers for which the algorithm isn't supposed to work, i.e. produce an error rather than have a special case only for numbers divisible by 2 but not for those divisible by 3, 5 and so on. I'm not sure if PRIME? should return true or false after an error, so I left that unchanged (it returns true).

The documentation states that PRIME? uses the absolute value of numbers but the original code explicitly (it didn't look like a typo) tested the sign to exclude negative numbers. I didn't change that and I suggest we keep this behavior because it makes sense and just update the documentation. But it'd be easy to use absolute values if that's what's desired. Please comment.