frollsd on ancient Windows can give NaN where NA is intended

[MichaelChirico]

As observed in R-CMD-check-occasional:

Test 6001.741 ran without errors but failed check that x equals y:
> x = frollsd(c(1.5, 2.5, 2, NA), c(3, 3)) 
First 2 of 2 (type 'list'): 
[[1]]
[1]  NA  NA 0.5 NaN

[[2]]
[1]  NA  NA 0.5 NaN

> y = list(c(NA, NA, 0.5, NA), c(NA, NA, 0.5, NA)) 
First 2 of 2 (type 'list'): 
[[1]]
[1]  NA  NA 0.5  NA

[[2]]
[1]  NA  NA 0.5  NA

Not clear how much effort it's worth expending on this. FWIW, Gemini thinks the root cause is:

• R $\le$ 3.6.3 (Rtools35): Built with GCC 4.9.3 + MinGW-w64 v4 against Microsoft's legacy MSVCRT.DLL. MSVCRT's sqrt() used legacy x87 FPU instructions that cleared double NaN payload bits, converting R's NA_REAL into generic NaN.
• R $\ge$ 4.0.0 (Rtools40): Upgraded the build toolchain to GCC 8.3 + MinGW-w64 v6. MinGW-w64 v6's C math library adheres to modern C99 IEEE 754 rules and preserves NaN payload bits during C sqrt() calls, preventing NA_REAL from being converted to NaN.

For now, I'll just mark this as skip with TODO.