Providing CppInterOp_DIR selects external mode: cppjit consumes that
CppInterOp install through find_package(CppInterOp) instead of building
one with ExternalProject and bundling it into the wheel.

In this mode nothing is bundled: the library and include paths from the
package config are baked into the wrapper as absolute paths, which
works because cppinterop_paths() joins with std::filesystem's
operator/, where an absolute right-hand side replaces the anchor. The
clang major comes from CPPINTEROP_LLVM_VERSION_MAJOR in the config, so
no LLVM is needed to build the wrapper itself; the LLVM discovery and
version gate only run in the default bundled mode, since compatibility
was already enforced when the external CppInterOp was built.

The mode is keyed to the explicitly provided CppInterOp_DIR variable,
not to find_package succeeding through ambient search paths: otherwise
a pip install inside e.g. a conda environment that happens to carry
CppInterOp would silently produce a wheel that does not bundle its
interpreter, making the wheel's composition depend on what the build
environment has lying around.

An external CppInterOp carries no clang builtin headers, and clang's
compiled-in resource dir default resolves relative to the library
location, so CPPJIT_CLANG_RESOURCE_DIR should point at the resource dir
matching the CppInterOp's clang. It is optional: when unset, CMake
warns and the wrapper falls back to the existing runtime
DetectResourceDir("clang-<major>") probe, which works wherever a
versioned clang is on PATH (e.g. conda environments). Distributions
where it is not (e.g. NixOS) pass the resource dir explicitly.

The config file's CPPINTEROP_INSTALL_PREFIX is captured immediately
after find_package, before the site-packages staging logic reuses that
variable name.

Intended for distribution packaging (e.g. Nix), where CppInterOp is a
separate package and duplicating its build in every consumer is wasted
work (e.g. for the matrix of different LLVM and Python versions
supported by Nix).