Fix linking of static archives with GCC with LTO

[lukel97]

Currently if you try to build llvm-test-suite with GCC and LTO, the MicroBenchmarks will fail to link.
Digging through the logs you'll find a warning earlier on:

libbenchmark.a(benchmark.cc.o): plugin needed to handle lto object

This is caused by CMake creating the library with ar and not gcc-ar, even though CMake finds gcc-ar:

// A wrapper around 'ar' adding the appropriate '--plugin' option for the GCC compiler
CMAKE_C_COMPILER_AR:FILEPATH=/home/igalia/luke/riscv-lnt/gcc-install/bin/riscv64-linux-gnu-gcc-ar

The fix is to set CMAKE_INTERPROCEDURAL_OPTIMIZATION which gets CMake to properly use the right ar/ranlib/etc. when using LTO.
We can set this in the cmake/caches/*LTO.cmake presets instead of manually adding the -flto flag which fixes the link error.

Unfortunately, CMake also sets -flto=thin for whatever reason on Clang. There's no way to configure it to do fat LTO, and there's a ton of open issues about this upstream: https://gitlab.kitware.com/cmake/cmake/-/issues/23136

It seems like the best way to workaround this is to just append -flto=auto in CXXFLAGS/LDFLAGS for Clang.

[asb]

Unfortunately, CMake also sets -flto=thin for whatever reason on Clang. There's no way to configure it to do fat LTO, and there's a ton of open issues about this upstream: https://gitlab.kitware.com/cmake/cmake/-/issues/23136

This suggests for gcc they pass -fno-fat-lto-objects - is that not the case? If so I think this patch would change the status quo for gcc. We should probably check via comparing the produced ninja build commands.

[lukel97]

This suggests for gcc they pass -fno-fat-lto-objects - is that not the case?

IIUC fat LTO objects means that the IR is embedded in the object files, not that the sources aren't partitioned, so -no-fat-lto-objects still optimises the whole program. I think the -flto=thin equivalent on GCC is -fwhopr