Bazel uses /usr/bin/clang instead of /usr/bin/clang++ to link C++ code on FreeBSD?

### Description of the problem / feature request:

Apparently, Bazel uses `/usr/bin/clang` instead of `/usr/bin/clang++` to compile/link C++ code. I'm not sure whether this is intentional, but the behavior for `clang` is different from `clang++` resulting in subtle problems at compile/link time:

```shell
❯ /usr/bin/clang -o bazel-out/freebsd-fastbuild/bin/time_zone_lookup_test '-Wl,-rpath,$ORIGIN/_solib_freebsd/' -Lbazel-out/freebsd-fastbuild/bin/_solib_freebsd bazel-out/freebsd-fastbuild/bin/_objs/time_zone_lookup_test/time_zone_lookup_test.pic.o -llibtime_Uzone -llibcivil_Utime -lexternal_Scom_Ugoogle_Ugoogletest_Slibgtest_Umain -lexternal_Scom_Ugoogle_Ugoogletest_Slibgtest -pthread -Wl,-S -lstdc++ -Wl,-z,relro,-z,now -no-canonical-prefixes
ld: error: bazel-out/freebsd-fastbuild/bin/_solib_freebsd/liblibtime_Uzone.so: undefined reference to ceilf
clang: error: linker command failed with exit code 1 (use -v to see invocation)

❯ /usr/bin/clang++ -o bazel-out/freebsd-fastbuild/bin/time_zone_lookup_test '-Wl,-rpath,$ORIGIN/_solib_freebsd/' -Lbazel-out/freebsd-fastbuild/bin/_solib_freebsd bazel-out/freebsd-fastbuild/bin/_objs/time_zone_lookup_test/time_zone_lookup_test.pic.o -llibtime_Uzone -llibcivil_Utime -lexternal_Scom_Ugoogle_Ugoogletest_Slibgtest_Umain -lexternal_Scom_Ugoogle_Ugoogletest_Slibgtest -pthread -Wl,-S -lstdc++ -Wl,-z,relro,-z,now -no-canonical-prefixes
```

The first command is what Bazel uses for purely C++ code on my FreeBSD system and the latter is what it should use. The only difference is `clang++` instead of `clang`.

### Feature requests: what underlying problem are you trying to solve with this feature?

**Perhaps use clang++/g++ for C++ code and clang/gcc for C code.** The problem is very likely `rules_cc` using `clang` instead of `clang++` as the C++ compiler in its toolchain definition. AFAIK, `clang` is the C compiler driver, not the C++ compiler driver. The two languages should use different rulesets as well: `cc_library`, `cc_binary` for C++ and `c_library`, `c_binary` for C code. AFAIK, C and C++ aren't the same.

### Bugs: what's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.

Compile anything using googletest on FreeBSD.

### What operating system are you running Bazel on?

- [x] FreeBSD 14-CURRENT amd64.

### What's the output of `bazel info release`?

```
>> bazel info release
release 6.0.0-2023-01-01 (@e724a5a)
```

### If `bazel info release` returns "development version" or "(@non-git)", tell us how you built Bazel.

> Replace this line with your answer.

### What version of rules_cc do you use? Can you paste the workspace rule used to fetch rules_cc? What other relevant dependencies does your project have?

- [x] `MODULE.bazel`
```
bazel_dep(name = "rules_cc", version = "0.0.2")
bazel_dep(name = "googletest", version = "1.11.0")
```

### What Bazel options do you use to trigger the issue? What C++ toolchain do you use?

No custom options. The default toolchain used for freebsd.

### Have you found anything relevant by searching the web?

Yes, apparently, everybody including me was getting around this by adding `-lm` linker flags until it was noticed that `/usr/bin/clang` is being used instead of `/usr/bin/clang++` to link C++ code. Here's [an example](https://github.com/bazelbuild/bazel/blob/ebf6a46e25d4be3bf0bbd77cb21dbff0276d5d04/src/tools/singlejar/BUILD#L95) from the Bazel source tree.

### Any other information, logs, or outputs that you want to share?

- [x] This was previously filed at: https://github.com/bazelbuild/bazel/issues/12023 for FreeBSD 12.0
- [x] Other issues: https://github.com/google/googletest/issues/3878 The `-lm` flags were added to `googletest` as a work around, but I'm not sure it is the correct solution. This needs to be fixed by separating cc_* from c_*, and by using `clang++` for C++ and `clang` for C code.

Start with the rules_cc toolchain definition and reproduce the reported googletest build on FreeBSD 14-CURRENT using the default toolchain. Compare the link behavior shown for /usr/bin/clang and /usr/bin/clang++, and review the referenced Bazel src/tools/singlejar/BUILD example. Done means C++ linking uses the appropriate driver without requiring the reported -lm workaround.

Written by the indexing model from the issue text.