Move non-target options from CompileTarget to CompileOptions

[lmondada]

This PR splits the options within CompileTarget into two structs: CompileTarget and CompileOptions. The target should focus on describing the target in a way that is agnostic of launch policy and execution details. The compile options on the other hand describe options that can apply to any target.

I'm mirroring the ADL pattern of finalize_execution_manager to keep the definitions of overloads ofget_compile_options for each policy next to the policy definition.

Motivation

The goal of this work is to render QPU::getCompileTarget independent of policy and QPU runtime configuration. The quantum platform should be able to query the compile target once and then store it. This separation is required to enable the compile-runtime split that #5005 introduces.

Illustration of the CompileTarget-CompileOptions split

To illustrate this, some of the flags that CompileTarget contains are:

• supportConditionalsOnMeasureResults: whether the target supports conditionals
• supportDeviceCalls: whether the target supports device calls
• the main pipelines to run at the different stages of compilation.

CompileOptions on the other hand contains:

• emitJit, emitResourceCounts: whether the compilation should produce a jitEngine or resource counts
• addMeasurements: whether to add measurements at the end of a kernel for sampling
• emulate: whether the compilation should be adjusted to target emulation

Remaining work

Looking at all implementations of QPU::getCompileTarget, the only blockers to unifying all overloads are

1. CompileTarget is still parametrised on the emulate and isLocalSimulator flags. We will be able to remove this once this flag can be queried from the runtime endpoint instead.
2. BaseRemoteRESTQPU::getCompileTarget(observe_policy, ...) sets target.pauliTermSplitObservable which informs the compiler whether the spin observable should be split at compilation time. The better solution would be to ONLY provide a custom implementation of observe when no splitting is required. Once we have runtime endpoints, we will be able to check whether a custom observe implementation is provided and otherwise fall back to decomposing the spin into multiple sample calls without involving the QPU.
3. (minor) BaseRemoteRESTQPU::getCompileTarget(dem_policy, ...) currently has an optimisation to bypass an unnecessary round-trip through the ServerHelper (which may trigger an API call). We should re-evaluate once everything else is in place whether this optimisation is worth keeping with some custom logic. If that is too brittle, accepting the extra API call is a reasonable fallback option.

[github-actions]

CI Summary (push) — ✅ passed

Run #30632084905 · ✅ 6 · ⏩ 7 · ❌ 0 · ⛔ 0

Top-level jobs (13)

Job	Result
binaries	⏩ skipped
build_and_test	✅ success
config_devdeps	✅ success
config_source_build	⏩ skipped
config_wheeldeps	✅ success
devdeps	✅ success
docker_image	⏩ skipped
gen_code_coverage	⏩ skipped
metadata	✅ success
python_metapackages	⏩ skipped
python_wheels	⏩ skipped
source_build	⏩ skipped
wheeldeps	✅ success

⏩ Skipped jobs (7) — intentionally skipped on PR builds; run on merge_group / workflow_dispatch

Job
binaries
config_source_build
docker_image
gen_code_coverage
python_metapackages
python_wheels
source_build

All sub-jobs (42) — every matrix leg, with links

Job	Status	Link
Build and test (amd64, gcc12, openmpi) / Dev environment (Debug)	✅ success	view
Build and test (amd64, gcc12, openmpi) / Dev environment (Python)	✅ success	view
Build and test (amd64, llvm, openmpi) / Dev environment (Debug)	✅ success	view
Build and test (amd64, llvm, openmpi) / Dev environment (Python)	✅ success	view
Build and test (arm64, llvm, openmpi) / Dev environment (Debug)	✅ success	view
Build and test (arm64, llvm, openmpi) / Dev environment (Python)	✅ success	view
CI Summary	❔ in_progress	view
Configure build (devdeps)	✅ success	view
Configure build (source_build)	⏩ skipped	view
Configure build (wheeldeps)	✅ success	view
Create CUDA Quantum installer	⏩ skipped	view
Create Docker images	⏩ skipped	view
Create Python metapackages	⏩ skipped	view
Create Python wheels	⏩ skipped	view
Gen code coverage	⏩ skipped	view
Load dependencies (amd64, gcc12) / Caching	✅ success	view
Load dependencies (amd64, gcc12) / Finalize	✅ success	view
Load dependencies (amd64, gcc12) / Metadata	✅ success	view
Load dependencies (amd64, llvm) / Caching	✅ success	view
Load dependencies (amd64, llvm) / Finalize	✅ success	view
Load dependencies (amd64, llvm) / Metadata	✅ success	view
Load dependencies (arm64, gcc12) / Caching	✅ success	view
Load dependencies (arm64, gcc12) / Finalize	✅ success	view
Load dependencies (arm64, gcc12) / Metadata	✅ success	view
Load dependencies (arm64, llvm) / Caching	✅ success	view
Load dependencies (arm64, llvm) / Finalize	✅ success	view
Load dependencies (arm64, llvm) / Metadata	✅ success	view
Load source build cache	⏩ skipped	view
Load wheel dependencies (amd64, 12.6) / Caching	✅ success	view
Load wheel dependencies (amd64, 12.6) / Finalize	✅ success	view
Load wheel dependencies (amd64, 12.6) / Metadata	✅ success	view
Load wheel dependencies (amd64, 13.0) / Caching	✅ success	view
Load wheel dependencies (amd64, 13.0) / Finalize	✅ success	view
Load wheel dependencies (amd64, 13.0) / Metadata	✅ success	view
Load wheel dependencies (arm64, 12.6) / Caching	✅ success	view
Load wheel dependencies (arm64, 12.6) / Finalize	✅ success	view
Load wheel dependencies (arm64, 12.6) / Metadata	✅ success	view
Load wheel dependencies (arm64, 13.0) / Caching	✅ success	view
Load wheel dependencies (arm64, 13.0) / Finalize	✅ success	view
Load wheel dependencies (arm64, 13.0) / Metadata	✅ success	view
Prepare cache clean-up	❔ in_progress	view
Retrieve PR info	✅ success	view

✅ Required checks (6/6) — declared in .github/required-checks.yml for push

Required check	Status	Link
Build and test (amd64, llvm, openmpi) / Dev environment (Debug)	✅ success	view
Build and test (amd64, llvm, openmpi) / Dev environment (Python)	✅ success	view
Build and test (arm64, llvm, openmpi) / Dev environment (Debug)	✅ success	view
Build and test (arm64, llvm, openmpi) / Dev environment (Python)	✅ success	view
Build and test (amd64, gcc12, openmpi) / Dev environment (Debug)	✅ success	view
Build and test (amd64, gcc12, openmpi) / Dev environment (Python)	✅ success	view

[Renaud-K]

Can this be in the detail namespace.

[Renaud-K]

Does it buy us a lot over

bool val = <true|false>

?