[hairez]

See #21. On Apple GPUs, normalize2 is merged into the next forward64_0, so each squaring has one kernel launch less.

• After normalize1, the next squaring runs forward64_0c: the work item that loads a vector k with k % NORM_WG_SZ == 0 adds c[k / NORM_WG_SZ] to it with the same arithmetic as normalize2.
• Every other access to the registers first runs normalize2 (flush()), so getInt and the checkpoints see the same data as now.
• Each work item reads the digit from its own prime's residue, not from P1 as normalize2 does, since the other residues are overwritten in place. That needs |d| < p / 2, and normalize1 writes |d| <= b + 1, so the host enables it only for 2 (b + 1) < min(P): every b <= 1e9, and with the U primes up to b = 1,971,322,879.
• It is used only where square() starts with forward64_0 (n != 18, 19, 20, 22), and not with TUNE.
• transformGPU.h switches it on only if _pEngine->isApple() and the conditions above hold. To try it on another GPU, replace _pEngine->isApple() with true. With FUSE_CARRY undefined, the kernel source after the preprocessor is token for token the same as main.

Speed of this change alone at n = 17, b = 514,400,002, with two PrimeGrid tasks on the same GPU, builds taking turns 8 times, 50,000 squarings per run: 111.7 microseconds per squaring before, 108.7 after, faster in 8 of 8 turns.

Tests:

• This branch: -q gives the expected results at n = 12 to 16, and a copy that drops the carry in carry_in() fails validation, so the merged path runs on the GPU.
• With Apple GPUs: Shoup multiplication by constants #22 and a test-only option, the raw digits after a given number of squarings hash the same as with both off at n = 12 to 18 and 21, 2 and 3 primes, S and U, on the multiply path, and on both sides of the b limit.
• Not run: n = 17 and above on this branch alone.