Set Intel compiler diag-disable flags when using Cray compiler wrappers

[climbfuji]

Resolves #47045 by updating the logic in lib/spack/spack/compilers/intel.py and lib/spack/spack/compilers/oneapi.py to set diag-disable flags for Intel compilers based on the version only (so that it works with Cray compiler wrappers). See #47045 for a description of the problem and why this solution works.

[scheibelp]

I have a couple questions:

• I forget why a %oneapi compiler can end up with cc = icc: is spack autodetecting that or are you generating manual entries? I'm trying to remember why this needed to be checked/handled in both %oneapi and %intel.
  • You mention in How to detect ifort when using Cray compiler wrappers so that SPACK_ALWAYS flags get set? #47045 that icx etc. handle these options fine, so this isn't a problem, but I would assume that icc would always be detected as %intel, and likewise manual entries could always record icc as %intel. That being said, even if %oneapi with icc can only occur manually, perhaps it is more robust to address that possibility (IMO a comment would be useful that such a configuration is atypical in spack).
• Do you know if the fortran wrappers will return a real version that is aligned with the intel compiler version?

[climbfuji]

I have a couple questions:

• I forget why a %oneapi compiler can end up with cc = icc: is spack autodetecting that or are you generating manual entries? I'm trying to remember why this needed to be checked/handled in both %oneapi and %intel.

  • You mention in How to detect ifort when using Cray compiler wrappers so that SPACK_ALWAYS flags get set? #47045 that icx etc. handle these options fine, so this isn't a problem, but I would assume that icc would always be detected as %intel, and likewise manual entries could always record icc as %intel. That being said, even if %oneapi with icc can only occur manually, perhaps it is more robust to address that possibility (IMO a comment would be useful that such a configuration is atypical in spack).

In an ideal world, %intel corresponds to icc, icpc, ifort and %oneapi corresponds to icx, icpx, ifx. In that case, the logic is only needed in %intel. But, in reality, %oneapi can also correspond to icx, icpx, ifort since ifx is still not ready for prime time (despite what Intel says, and despite the fact that oneapi@2024.2.1.??? was the last ever release of ifort). I don't think anyone will ever try to mix and match icx with icpc or vice versa. icc+icpc will always be %intel, and icx+icpx will always be %oneapi. Therefore, we really only need the Fortran part of the logic in the oneAPI case.

• Do you know if the fortran wrappers will return a real version that is aligned with the intel compiler version?

I assume this refers to the Cray wrapper ftn. Yes, the Cray wrapper passes --version through to the actual compiler, you get the same as if you were running ifx --version, ifort --version when PrgEnv-Intel is loaded.

[scheibelp]

based on the conversation, this looks mostly good, but I have a request about documentation