cmake: force-disable unity for clang-tidied build targets only

[vszakats]

Instead of globally disabling unity for all targets when clang-tidy is
enabled.

After this patch CMAKE_UNITY_BUILD=ON is honored for:

• static libcurl when building both static and shared separately.
• libcurlu and libcurltool internal libraries when building the test
  target.

While keeping unity disabled for the libcurl build pass running
clang-tidy, and the curl tool, also running clang-tidy.

To make clang-tidy-enabled builds finish faster when unity mode is
enabled, yet performs the same clang-tidy checks as before this patch.

Effect on:

• GHA/macos: core build: same, buils tests 5-12 seconds faster,
  with steps going down from 259 to 25.

  52s: https://github.com/curl/curl/actions/runs/22279958340/job/64448913325 ->
  47s: https://github.com/curl/curl/actions/runs/22279873606/job/64448710743

• GHA/windows (not enabled): it'd save about 1 minute, bringing total
  time barely below 10m, still one of the slowest jobs overall.
  (cmake: add native clang-tidy support for tests, with concatenated sources #20667 is trying a way for 4x speed-up (with a drawback)).

  5m21s: https://github.com/curl/curl/actions/runs/22222907068/job/64284556852 ->
  4m26s: https://github.com/curl/curl/actions/runs/22281033369/job/64451601548

Closes #20670

---

https://github.com/curl/curl/pull/20670/files?w=1

• consider enabling unity for libcurlu and libcurltool permanently (as in 'initial idea' below). [OTHER PR] → cmake: always build curlu and curltool test libs in unity mode #20677

• additional opportunity is to selectively disable unity for the shared libcurl only, when building both shared and static. This has no downside AFAICS.

• initial idea: always enable unity for internal libs curlu and curltool:

  • + unity tested even more, better perf by def when building tests, better perf in cases needing no-unity.
  • - units/tunits always test against unity-made libs with cmake, libcurlu and libcurltool is no longer clang-tidy tested (curlu has a bunch of UNITTEST-only function, curltool does not [edit: this is moot: clang-tidy is already explicitly disabled for curlu and curltool since ccb6564 cmake: omit clang-tidy on internal libs curlu and curltool #17693).

• alternative take: consider force-disabling unity only for targets checked with clang-tidy when clang-tidy is enabled. (More complex, more limited, possibly safer, more flexible?) → went with this one.

[vszakats]

Fun fact: clang-tidy may still check into system headers without the --system-headers option set
(or explicitly disabled via SystemHeaders: false config), this, combined with --fix (or
--fix-error or a combination of them) may result in editing and silently breaking for example
Homebrew OpenSSL headers. Causing surprise and fatal clang-diagnostic-error errors on next runs.

I find it unpredictable which included file / header is checked by clang-tidy.

E.g. the manual page https://clang.llvm.org/extra/clang-tidy/index.html says --header-filter=<string>
has the default value of .*, yet, with the default, it doesn't check local/private headers included via
#include "name.h". When setting --header-filter=.* (or HeaderFilterRegex: '.*' via config), it
does, but then it also looks into macOS SDK and libssh2 headers. Both included with <>, the former
presumably via -isysroot (implicitly by clang), the latter on an explicit -isystem header path.

Correction: The v23 (dev) docs mention these as defaults. The v21 (stable, as used in these tests)
one https://releases.llvm.org/21.1.0/tools/clang/tools/extra/docs/clang-tidy/index.html does not say
say about defaults.

Hard to say if this is a documentation fix, or maybe .* becomes the default on the next release,
and/or maybe this means it got fixes which will have made this safe. edit: Indeed, .* became the default in v22.1.0: https://releases.llvm.org/22.1.0/tools/clang/tools/extra/docs/ReleaseNotes.html#improvements-to-clang-tidy

edit: fix → #20724

[vszakats]

I find it unpredictable which included file / header is checked by clang-tidy.

It turned out to be my mistake. System headers were picked accidentally
when using the manual clang-tidy method used for tests with cmake. This
needs manually reconstructing the C compiler command-line, including
headers path. When doing this, my code added all of them with -I, meaning
system (and 3rd-party) ones too. This made them appear as local headers
for clang-tidy.

Testing and fixing in #20720, and it'll become a separate PR. → #20724