Scanf parsing reads the longest possibly valid prefix for a given
conversion. Then, it performs the conversion on that string. In the case
of "0xZ" with a hex conversion (either "%x" or "%i") the longest
possibly valid prefix is "0x", which makes it the "input item" (per the
standard). The sequence "0x" is not a "matching sequence" for a hex
conversion, meaning it results in a matching failure, and parsing ends.
This is because to know that there's no valid digit after "0x" it reads
the 'Z', but it can only put back one character (the 'Z') leaving it
with consuming an invalid sequence.

(inspired by a thread on the libc-coord mailing list: 
https://www.openwall.com/lists/libc-coord/2024/10/15/1, see 7.32.6.2 in
the standard for more details.)

https://github.com/llvm/llvm-project/issues/60481

Summary:
We can enable the sscanf function on the GPU now. This required adding
the configs to the scanf list so that the GPU build didn't do float
conversions.

Umbrella bug #83182

- [libc][NFC] Rename FPBits nan functions
- rename build_signaling_nan in signaling_nan
- rename build_quiet_nan to quiet_nan

- reland #79113
- Fix aarch64 RISC-V build

Reverts llvm/llvm-project#79113
It broke aarch64 build bot machines.

This patch reduces the surface of `FPBits`.