map llvm.maxnum to NMax instead of FMax and llvm.minnum to NMin instead of FMin

[farzonl]

FMax (Floating-Point Maximum):

• Result is y if x < y.
• If both x and y are zeros, either x or y is the result.
• If one operand is NaN (Not a Number), the result is the - other operand (the non-NaN operand).
• If both operands are NaN, the result is undefined.

NMax (NaN-Aware Maximum):

• Result is y if x < y.
• If both x and y are zeros, either x or y is the result.
• If one operand is NaN, the other operand is the result.
• If both operands are NaN, the result is NaN.

FMax is undefined if one of the operands in NaN,
 so in DXC we use NMax to match HLSL max. 
It looks like that matches the LLVM instrinsic semantics, 
so I think this will be a straightforward SPIR-V backend change, 
but we do have to check that it doesn't break anything for the OpenCL side. 

Originally posted by @sudonatalie in #86844 (comment)

This issue is to track the work to SPIRVInstructionSelector.cpp and make sure changing the TargetOpcode to GL::FMin GL::FMax doesn't break OpenCL.
https://github.com/llvm/llvm-project/blob/main/llvm/lib/Target/SPIRV/SPIRVInstructionSelector.cpp#L433C1-L438C67

I suspect we will be able to change

...
selectExtInst(ResVReg, ResType, I, CL::fmin, GL::FMin);
...
selectExtInst(ResVReg, ResType, I, CL::fmax, GL::FMax);

to

...
selectExtInst(ResVReg, ResType, I, CL::fmin, GL::NMin);
...
selectExtInst(ResVReg, ResType, I, CL::fmax, GL::NMax);

without effecting openCL.