cmake: make ccache opt-in when Tracy is consumed as a subdirectory dependency

[blozano-tt]

Problem

cmake/config.cmake sets the global CMake property RULE_LAUNCH_COMPILE ccache whenever ccache is found and NO_CCACHE is off (the default). This is appropriate when building Tracy directly, but when Tracy is consumed as a subdirectory dependency via add_subdirectory(), the global property leaks into the parent build.

If the parent project already manages ccache — for example via CMAKE_CXX_COMPILER_LAUNCHER — both mechanisms activate at the same time. CMake then generates Ninja rules that double-wrap the compiler:

```
ccache cmake -E env CCACHE_SLOPPINESS=... ccache clang++ -c foo.cpp
```

The outer ccache invocation sees cmake (not clang++) as the compiler and rejects every translation unit with "Multiple source files".

Real-world impact: after integrating Tracy into tenstorrent/tt-metal, 1856 of 2248 compilations became uncacheable (82.6% miss rate). The project was forced to work around it with set(NO_CCACHE ON) before the Tracy add_subdirectory calls (tenstorrent/tt-metal#47617). This fix addresses the root cause upstream.

Fix

Detect whether Tracy is the top-level CMake project at configure time:

• Top-level: NO_CCACHE defaults to OFF — ccache enabled, existing behavior preserved for Tracy CLI users building Tracy directly.
• Subdirectory dependency: NO_CCACHE defaults to ON — the global RULE_LAUNCH_COMPILE property is not set, preventing leakage into the parent build. Parent projects that explicitly want Tracy's ccache can still pass -DNO_CCACHE=OFF.

This makes ccache opt-in when Tracy is used as a dependency, matching the principle of least surprise for CMake consumers.

Testing

Build Tracy CLI tools directly — behaviour unchanged (ccache still active by default).

Consume Tracy as a subdirectory in a project that sets CMAKE_CXX_COMPILER_LAUNCHER=ccache — no more double-wrapping; the parent's ccache operates correctly.

[wolfpld]

Why are you trying to build Tracy tools as a part of some external project?

[mo-tenstorrent]

We use them to systematically capture and export tracy runs. Single build builds them all. If they have tracy enabled they are going to need the tools as well.

[wolfpld]

I don't think adapting to any possible external build configuration is what I want to do (except for the client, of course).

https://cmake.org/cmake/help/latest/module/ExternalProject.html is probably the solution you're looking for.