This PR makes some minor simplifications to the implementation of math.isqrt. Those simplifications improve the speed of math.isqrt for inputs smaller than 2**64 by around 20% on my machine.

In detail:

• In _approximate_sqrt, use a lookup table based on the topmost 8 bits to replace the first two Newton iterations. This reduces the total number of divisions needed from 4 to 2.
• Change the return type of _approximate_sqrt from uint64_t to uint32_t.
• Replace the u * u - 1U >= m test with the simpler but equivalent test u * u > m.
• Add casts to make it clear to the compiler that a 32-bit-by-32-bit division is enough for the first of the two divisions in _approximate_sqrt (though I'd expect most compilers not to need this).
• Suggest to the compiler that _approximate_sqrt be inlined.
• Simplify the shift computation.

On my Intel x64 machine, the assembly produced by Clang involves one divl instruction and one divq instruction.

There's one subtle but important change here: in the previous implementation of _approximate_sqrt, it was possible for the returned value to be exactly 2**32 (but no larger), so we couldn't assume that it would fit in a uint32_t. With the new code, the returned value is always < 2**32. It's this fact that makes it possible to change the return type, and to replace the u*u - 1 >= m test with u*u > m. To prove this bound: if we ignore overflow for the moment, since the result of _approximate_sqrt is always within 1 of the true square root (following the proof already outlined in the comments), the only way that the result of the final addition can be 2**32 (overflowing to 0) is if the input n exceeds (2**32 - 1)**2. But in that case we know most of the top bits of n: the top 32 bits are either 0xfffffffe or 0xffffffff, and so we can trace through the first steps of _approximate_sqrt - the value of u retrieved from the lookup table is 255, then the value assigned to u in the following line is 65536. Then it's easy to see that if u = 65536, (n >> 17 / u) < 2**31 and u << 15 = 2**31, so the result of the addition fits in a uint32_t.

https://bugs.python.org/issue46258