Add centralized flag system for TheRock

[stellaraccident]

Summary

• Introduces a central flag registry (FLAGS.cmake) with automated CMake variable and C preprocessor define propagation to subprojects
• Each flag is declared with therock_declare_flag() and controlled via THEROCK_FLAG_{NAME} cache variables
• Supports BRANCH_FLAGS.cmake for integration branches to override flag defaults
• Flag states are recorded in therock_manifest.json
• Migrates THEROCK_KPACK_SPLIT_ARTIFACTS → THEROCK_FLAG_KPACK_SPLIT_ARTIFACTS as the first flag
• Removes THEROCK_KPACK_DIR cache variable (hardcoded to rocm-systems path)
• Documentation in docs/development/flags.md

Test plan

• cmake -B build -S . -GNinja -DTHEROCK_AMDGPU_FAMILIES=gfx1201 — flag defaults OFF, no kpack targets
• cmake ... -DTHEROCK_FLAG_KPACK_SPLIT_ARTIFACTS=ON — rocm-kpack included, ROCM_KPACK_ENABLED=ON injected into hip-clr _init.cmake
• flag_settings.json generated in build dir with correct flag states
• BRANCH_FLAGS.cmake with therock_override_flag_default(KPACK_SPLIT_ARTIFACTS ON) overrides default and logs message
• CI configure passes with flag OFF (default)

🤖 Generated with Claude Code

[stellaraccident]

Stash the default value in a property and don't manipulate the CACHE vars here. Then in the override function, just update the property. Do all global/cache manipulation in finalize in order to avoid set-ordering fiascos.

[stellaraccident]

Reviewers: I've already done a detailed review and applied one round of feedback. More welcome, but this LGTM.

[ScottTodd]

Migrates THEROCK_KPACK_SPLIT_ARTIFACTS → THEROCK_FLAG_KPACK_SPLIT_ARTIFACTS as the first flag

Do you have a list of existing flags that could also be migrated? I'm wondering about the scope of how much this system will be used.

My code review agent had some thoughts:

The main near-term candidate is THEROCK_SANITIZER, which already uses its own bespoke project_init.cmake injection in therock_sanitizers.cmake. Migrating it would validate the flag system's expressiveness for non-trivial cases (it has per-subproject overrides and compiler flag stanzas). Other options like THEROCK_SPLIT_DEBUG_INFO, THEROCK_MINIMAL_DEBUG_INFO, and THEROCK_COMPILER_RT_DEBUG could also migrate if they inject into subprojects. The THEROCK_ENABLE_* feature flags are a separate system and wouldn't use this. Beyond existing options, the system is designed for new integration flags (like the kpack work) where a top-level decision needs to propagate cmake vars or defines into specific subprojects

[stellaraccident]

The KPACK flag is the only ephemeral feature flag we will enable right now (i.e. this is a new feature and we will eventually retire the flag once launched).

I am considering some more permanent flags that need coordination across the codebase. Top of my list is FLANG.

In general, my priority with this is to have a facility so that dev teams have no friction for doing flag based development of new features. Right now, we just say "use flags" but then no one knows how to do that. I'm going to focus there on process improvement.