Introduce backend independent acquisition mappings (SE-386)

Explanation of changes

Overview

This change is part of acquisition redesign (&5), and is intended to partially replace the current acquisition metadata. This change only introduces some new acquisition mappings, but ultimately does not use it anywhere to make the MR relatively short. (In a subsequent MR we will use it.)

The change is the following.

1. It introduces two acquisition mappings, both of them are backend independent mappings.
   • AcquisitionChannelData, which contains the following for each acquisition channel.
     • acquisition protocol,
     • bin mode,
     • coords.
   • SchedulableLabelToAcquisitionIndex, which is a mapping for each schedulable to acquisition index.
2. Replaces the operation's internal structure a little bit, the acq_index is stored under the coords now.

This MR only implements the introduction of the backend-independent acquisition mappings (1st step) in 5. Implementation for quantify-scheduler!

Motivation of changes

Please first take a look at the agreed interface design to understand the motivation: Implementation plan for Quantify-scheduler.

New acquisition mappings

First, read 5. Implementation for quantify-scheduler.

This MR only implements the introduction of the backend-independent acquisition mappings (1st step)!

coords vs acq_index

The reason we would introduce coords, and store acq_index in coords["index"] is that with the new mapping, the acq_index will have a different meaning: it is not something the user sets, but rather, this is a compiler generated value. In the examples, this is for example the values of acq_index_ch_0. But in the meantime (while acquisition redesign is not completely ready) we can't change the interface, because we don't want to implement all the changes in one MR (would be too big). So, we need to store the user defined acq_index somewhere, and coords is a fitting place, because that's exactly what it is: it's a user appended value to the acquisition.

Throughout the codebase, we will use the coords["index"] to store the user defined acq_index.

This is confusing, but only a temporary solution, until we don't implement the coords to the interface.

---

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 and entry in deprecated code suggestions (or N/A).
• Newly added/adjusted documentation and docstrings render properly (or N/A).
• Pipeline fix or dependency update: post in #software-for-developers channel to merge main back in or update local packages (or N/A).
• Tested on hardware (or N/A).
• CHANGELOG.md and AUTHORS.md have been updated (or N/A).
• Performance tests: if changes can affect performance, trigger CI manually and evaluate results (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.