integerNthRoot() is unnecessarily nonmonotonic

[ds26gte]

integerNthRoot() for positive args should arguably be monotonically nondecreasing. Instead our implementation has it take a sawtooth pattern that defeats understanding. E.g.,

integerNthRoot(3, 7.5) => 4
integerNthRoot(3, 8)   => 2
integerNthRoot(3, 8.5) => 4

I think it should be 1, 2, 2. I.e, it should return the largest integer which when raised to the first arg gives a result that is <= the second arg. 2, 2, 3 is also a possibility. (Even more bizarre fluctuations are obtained if the arguments are negative.)

This error mostly doesn't operationally matter, because user-level Pyret doesn't exercise it for non-integral second arg. But the fix is easy, and makes it more robust for JS-level use of this and the related nthRoot() functions.

We can also formally force the domain of integerNthRoot() to be non-negative for both args. nthRoot() can take a negative second arg, but it only ever calls integerNthRoot() with both non-negative args. There is no need to take the arithmetic effort to make integerNthRoot() robust for a negative args.

[schanzer]

Tagging #1818 so that this issue can be closed when that PR is merged.