New compilation node `set_pulse_and_acquisition_clock` to check and/or set clock frequency (#371, QAE-449, QAE-481)

Explanation of changes

note 1: there is a typo in the branch name fix_pulse_clock_verfication.

note 2: test notebook test_fix_pulse_clock_verification.ipynb

note 3: multiply defined clocks raise a warning, and it is the frequency that is set at the schedule level, which is taken into account in this case.

The new compilation node, defined inside circuit_to_device.py ensures that each pulse/acquisition-level clock resource has either been added to the schedule or, if present in device_cfg, adds it to the schedule. An error is raised if the clock resource is unknown and a warning if it is multiply defined. Closes #371 (closed)

Tests:

Multiple tests had clock conflicts. These have been resolved on a case-by-case basis, with the following rationale:

• Ideally, since there is always a device configuration with SerialCompiler the clock should be added to the device layer if the user creates it (usually when there are gate operations). The new node will add it automatically to the schedule.
• In the case of pulse-only schedules, since the user does not need to create a device config, the clock is manually added to the schedule.

Motivation of changes

1. Previously, for pulses, the clock resource needed to be added manually to the schedule. This is not a huge problem when only pulses are used. However, if the schedule mixes gates and pulses, it requires the manual addition of the clock resource to the schedule, even if it is already defined in the device config.
2. Previously, for pulse-only schedules, when there was no circuit-to-device compilation, there was no verification of the clock (it was done in the circuit-to-device compilation, see 1). As such, no error appeared when compiling the circuit to hardware. This error should appear since the clock is required.

---

Merge checklist

See also merge request guidelines

• Merge request has been reviewed (in-depth by a knowledgeable contributor), and is approved by a project maintainer.
• New code is covered by unit tests (or N/A).
• New code is documented and docstrings use numpydoc format (or N/A).
• New functionality: considered making private instead of extending public API (or N/A).
• Public API changed: added @deprecated (or N/A).
• Tested on hardware (or N/A).
• CHANGELOG.md and AUTHORS.md have been updated (or N/A).
• Windows tests in CI pipeline pass (manually triggered by maintainers before merging).

---

For reference, the issues workflow is described in the contribution guidelines.