build: use PROJECT_IS_TOP_LEVEL for the pkgconfig top-level guard

[bobluppes]

Why

#312 fixed the FetchContent crash from #310 by skipping the pkgconfig install block unless Graaf is the top-level project, via CMAKE_SOURCE_DIR STREQUAL PROJECT_SOURCE_DIR. CMake 3.21+ exposes exactly this as the built-in PROJECT_IS_TOP_LEVEL variable, which is clearer and self-documenting -- but this project's floor is CMake 3.11, so it isn't guaranteed to be defined.

What Changed

Defines PROJECT_IS_TOP_LEVEL ourselves (matching CMake's own semantics) when it isn't already set by CMake, and uses it for the pkgconfig guard instead of the raw path comparison. No behavior change; same guard, clearer name, and reusable if more top-level-only logic gets added later.

Verification

Built and installed locally in both scenarios:

• As the top-level project: graaf.pc is still generated and installed.
• As a FetchContent dependency of a throwaway consumer project: no .pc file is generated (matching Fix FetchContent following 2a4715ff46a25048e06078ea20afc325d59f987a #312's intended behavior), headers still install correctly.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 99.58%. Comparing base (4b0ad5a) to head (8fd7055).

Additional details and impacted files

@@           Coverage Diff           @@
##             main     #348   +/-   ##
=======================================
  Coverage   99.58%   99.58%           
=======================================
  Files          59       59           
  Lines        2622     2622           
  Branches      136      136           
=======================================
  Hits         2611     2611           
  Misses         11       11           

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[bobluppes]

Closing this — on reflection there's a real gap: my verification only ran on CMake 4.4.3, so the CMake<3.21 fallback branch (guarded by if(NOT DEFINED PROJECT_IS_TOP_LEVEL)) never actually executed, since modern CMake already defines the variable before that check runs. Worse, that guard has a real bug: plain CMake variables are inherited into subdirectories, so if a consuming project already sets PROJECT_IS_TOP_LEVEL for itself, that value would leak into Graaf's scope and the fallback would skip recomputing it for Graaf specifically. Not worth pursuing further -- the CMAKE_SOURCE_DIR STREQUAL PROJECT_SOURCE_DIR check from #312 stays as the correct, version-portable approach.