Draft: Determine abs_time recursively

Explanation of changes

• Determine schedulables' abs_time recurcively in the determine_abs_timing compilation function
• An error should be raised if a loop is detected in the timing constraints

Motivation of changes

---

determine_abs_timing compilation step only works when the schedulables are added in a specific order to the schedule (when all ref_scheduables of a schedulable's timing constraints have been added to the schedule before it). This is a constraint for the user that we want to avoid. Recursively determining the abs_time of each schedulable solves this problem.

This change is only relevant if users are allowed to build their schedule with schedulable.add_timing_constraint (if users can only use Schedule.add, they can never add a timing_constraint["ref_schedulable"] which was added later to the schedule).

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).
  • Maintainers do not hit Auto-merge, we need to actively check as manual tests do not block pipeline

---

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