edge case behavior for fract

From a discussion in the SPIR call on November 15th (see also internal SPIR-V issue 768):

OpenCL defines the following edge case behavior for the `fract` built-in function - see [link](https://registry.khronos.org/OpenCL/specs/3.0-unified/html/OpenCL_C.html#additional-requirements-beyond-c99-tc2). These requirements have been in place since OpenCL 1.0:

fract(x, iptr) shall not return a value greater than or equal to 1.0, and shall not return a value less than 0.
fract(+0, iptr) returns +0 and +0 in iptr.
**fract(-0, iptr) returns -0 and -0 in iptr.**
fract(+∞, iptr) returns +0 and +∞ in iptr.
**fract(-∞, iptr) returns -0 and -∞ in iptr.**
fract(NaN, iptr) returns the NaN and NaN in iptr.

It doesn't look like all of these edge case conditions are tested in the CTS tests though, and for the conditions in **bold**, several implementations that I've tested are returning `+0` instead of `-0`.

Does anyone recall why these edge cases are defined as they are? Is it to match the semantics of the C99 `modf`, which is specified to return values "each having the same type and sign as arg"?

Compare the OpenCL fract requirements in the linked OpenCL 3.0 specification with C99 modf semantics, focusing on signed zero and infinity. Review the existing CTS coverage for fract edge cases, then document the rationale and identify which bold conditions are missing tests; done means the behavior and coverage gaps are resolved or clearly recorded.

Written by the indexing model from the issue text.