define semantics for floating-point min and max collective functions

The semantics for the floating-point min and max collective functions (e.g. work_group_scan_inclusive_min) are currently undefined, especially for NaNs.

https://registry.khronos.org/OpenCL/specs/3.0-unified/html/OpenCL_C.html#work-group-functions

Should these functions behave as though the operator were the fmin of fmax built-in funcitons, which have defined NaN behavior? Example for fmin: "Returns y if y < x, otherwise it returns x. If one argument is a NaN, fmin() returns the other argument. If both arguments are NaNs, fmin() returns a NaN"

Or should these functions behave as though the operator were the min or max built-in functions, which have no defined NaN behavior? Example for min: "Returns y if y < x, otherwise it returns x. If x or y are infinite or NaN, the return values are undefined."

Or, should these functions behave some other way?

For reference, the CTS tests appear to be using std::min and std::max, though perhaps this is incorrect:
https://github.com/KhronosGroup/OpenCL-CTS/blob/main/test_conformance/workgroups/test_wg_scan_reduce.cpp#L75

Once we have settled on what should be happening in OpenCL C we should document the SPIR-V behavior also, either in the main SPIR-V spec (by updating the descriptions for OpGroupFMin and OpGroupFMax), or by updating the OpenCL SPIR-V environment spec.

Start with the OpenCL C work-group-functions section and the CTS reference in test_conformance/workgroups/test_wg_scan_reduce.cpp. Review the NaN behavior options for the floating-point min and max collectives, then determine the corresponding SPIR-V documentation location. Done means the semantics are agreed and documented in OpenCL C and the applicable SPIR-V specification.