WIP: [ci] [R-package] drop 'icc' test job, update clang and GCC r-hub container jobs

[jameslamb]

Fixes #7221

Intel stopped shipping icc in 2024. From https://www.intel.com/content/www/us/en/developer/articles/release-notes/oneapi-c-compiler-release-notes.html

Intel® C++ Compiler Classic (icc) is deprecated and was discontinued in the oneAPI 2024.0 release.

And R Hub removed their intel container image last month: r-hub/containers@a447464#diff-1645e8921051d59c6ea1f1f10e1926a1891fce8f0351bc427bff02ef3650d4eb

I think that's why R CI jobs using that intel container image are failing here... packages have made it to CRAN which rely on features in R-devel that are too new for the version in those no-longer-published images.

This proposes the following for R CI:

• drop intel job
• add clang22 job (previous max clang tested: clang20)
• add gcc16 job (previous max gcc tested: gcc 14)
• remove interemediate clang and gcc R CI jobs

Notes for Reviewers

Why not add a job using icx?

Intel does have a new compiler replacing icc:

Intel recommends that customers transition now to using the LLVM-based Intel® oneAPI DPC++/C++ Compiler (icx)

But I'm not aware of an easy-to-use container image with it + R installed, and it isn't required for CRAN submissions: https://cran.r-project.org/web/checks/check_flavors.html#r-devel-linux-x86_64-debian-clang

Even outside of R, I personally don't want to spend time trying to add a icx support + a CI job for it here until someone asks for it.

Why cut out those other clang and gcc jobs?

Since the project moved out of the microsoft/ org (#7187), we face lower maximum number of concurrent CI jobs. Proposing only testing endpoints of the support matrix to reduce the total number of jobs. That should be enough to catch most compatibility problems, and keep in mind that we do probably end up testing intermediate versions in other jobs via Linux distributions choosing versions somewhere in the middle of the range.