[clang-tools-extra] [clangd] Add new highlighting modifier `CommandLineDefined`. (PR #175495)

[via cfe-commits]

anonymouspc wrote:

> Can you elaborate on the motivation for this? What are some scenarios in which it's necessary or important for a user to distinguish between macros defined in source code and macros defined on the command-line?

Here are a few scenarios:

1. Users need to know whether a macro is fixed (defined as part of the source) or configuration-dependent (supplied by the build).
   - **source-defined** macros are typically part of an API contract or an implementation technique. For example:
     - `stdin`, `offsetof`
     - `UINT8_MAX`
     - `BOOST_FUSION_ADAPT_STRUCT`, `BOOST_PP_REPEAT`
     
     They generally aren’t meant to be toggled per build.

   - **command-line-defined** macros are commonly used to select between build variants. For example:
     - `DEBUG`, `NDEBUG`
     - `PKG_STATIC`, `PKG_SHARED`,
     - `_GLIBCXX_USE_CXX11_ABI`. 
     
     These can change depending on the compile command, CMake options, toolchain, etc.

2. Editors/IDEs may want to visually de-emphasize code that is never reachable under the current configuration, but should be careful **not to mislead the user**. For example, 
   - code guarded by `#if __cpp_concepts`, `#if __cpp_lib_ranges` can be safely dimmed in `-std=c++17`.
   - code guarded by `#if NDEBUG`, `#if TBB_SHARED` is dependent on command line. They should not be treated as dead code in the same way.
  
-----

I’m adding an additional flag so that:
- Users who care about the distinction (like me) can quickly identify command-line-defined vs source-defined macros.
- Users who don’t care can ignore it without changing their workflow.

https://github.com/llvm/llvm-project/pull/175495