Incorrectly adding `-xobjective-c++` on linker step MacOS (cmake)

Nobody has claimed this yet.

I have the following build rule to build a cmake based project ([SFML](https://github.com/SFML/SFML)).
```bazel
load("@rules_foreign_cc//foreign_cc:defs.bzl", "cmake")

# This rule invokes CMake to build SFML and wraps the output in a cc_library.
cmake(
name = "sfml_libs",
# The source code for the library is the entire SFML repository.
lib_source = "@sfml//:all_srcs",
# Pass configuration options to CMake.
cache_entries = {
"SFML_BUILD_GRAPHICS": "TRUE",
"SFML_BUILD_WINDOW": "TRUE",
"SFML_BUILD_AUDIO": "TRUE",
"SFML_BUILD_NETWORK": "TRUE",
"SFML_BUILD_SYSTEM": "TRUE",
"BUILD_SHARED_LIBS": "FALSE", # Build static libraries
},
# Ensure all files are available to the build rule.
visibility = ["//visibility:public"],
)
```

in my MODULE.bazel, I have the following:
```bazel

bazel_dep(name = "rules_foreign_cc", version = "0.15.0")
bazel_dep(name = "rules_pkg", version = "1.0.1")

# Import the git_repository rule
new_git_repository = use_repo_rule(
"@bazel_tools//tools/build_defs/repo:git.bzl",
"new_git_repository",
)

new_git_repository(
name = "sfml",
build_file = "@//third_party/sfml:sfml.BUILD",
remote = "https://github.com/SFML/SFML.git",
tag = "3.0.1"
)
```

However, the build fails. I've spent days trying to narrow down the source of the problem, but it basically boils down to cmake trying to add both the compiler and linker flags to the link phase, which results in an error due to `-xobjective-c++` being included which tells clang to expect objective-c++ source files instead of the object (.o) files during the linking phase.

` /private/var/tmp/_bazel_brad/52e8eb7db9182d9c84da02094e51c975/execroot/_main/external/rules_cc++cc_configure_extension+local_config_cc/cc_wrapper.sh -U_FORTIFY_SOURCE -fstack-protector -Wall -Wthread-safety -Wself-assign -Wunused-but-set-parameter -Wno-free-nonheap-object -fcolor-diagnostics -fno-omit-frame-pointer -g0 -O2 -D_FORTIFY_SOURCE=1 -DNDEBUG -ffunction-sections -fdata-sections -std=c++17 -mmacosx-version-min=15.5 -no-canonical-prefixes -Wno-builtin-macro-redefined -D__DATE__=\"redacted\" -D__TIMESTAMP__=\"redacted\" -D__TIME__=\"redacted\" -xobjective-c++ -arch arm64 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX15.5.sdk -mmacosx-version-min=13.0 -Wl,-search_paths_first -Wl,-headerpad_max_install_names -mmacosx-version-min=15.5 -no-canonical-prefixes -fobjc-link-runtime -headerpad_max_install_names -Wl,-dead_strip -lc++ -lm CMakeFiles/cmTC_a181b.dir/testCXXCompiler.cxx.o -o cmTC_a181b
`

As you can see, the above linker invocation on `testCXXCompiler.cxx.o` fails because of the preceding `-xobjective-c++` flag. It's treating `testCXXCompiler.cxx.o` as a text file and then fails with a large number of `source file is not valid UTF-8` errors. The problem is that something (cmake? bazel toolchain?) is adding the compile flags before the linker flags. The linker phase should only include the linker flags.

I don't know where the problem is coming from, but I can build the project without issue using regular cmake on Mac, but using foreign_cc `cmake` build rule fails due to this issue. I've tried a few older `foreign_cc` and `bazel` version with no luck.

Start with the rules_foreign_cc cmake rule and the generated cc_wrapper.sh invocation shown in the report. Reproduce the SFML 3.0.1 build on macOS, then trace why -xobjective-c++ from the compile configuration reaches CMake's testCXXCompiler.cxx.o link step. Done means the CMake compiler test and the foreign_cc build complete without passing source-language flags to the linker.

Written by the indexing model from the issue text.