feat: Qblox backend to use new acquisition mappings

Explanation of changes

This is part of &5 (closed).

More specifically, this implements the 4. and 5. part of the section 5. Implementation for Quantify-scheduler.

Simple explanation

The acquisition hardware mapping determines which hardware location (sequencer, Qblox acquisition index, bin) is associated with which acquisition channel and acquisition index. This mapping is generated at compilation phase (compiler_abc.py), and then after the schedule ran on the hardware, the instrument coordinator retrieves the data from the hardware, and it needs to map the hardware data to some xarray data (which only contains acquisition channels and acquisition indices, but not where it came from in the hardware).

This is achieved by making "acquisition metadata" redundant (unused completely), and using instead the "acquisition channels data" and "acquisition hardware mapping".

Some details

• Since this MR changes which acquisition index corresponds to which bin (in compilation), we need to also change the instrument coordinator that maps the bins to acquisition indices.
• Previously, for each acquisition channel, the compiler generated only one bin register. This is incorrect. The instrument coordinator needs to know which bins correspond to the first operation, and which to the second, etc. (This will be important to decide when we add the "labels" or "coords" to acquisition operations: we need to add this to the return data too, and need to know which bit they correspond to.) Imagine a schedule with multiple append acquisitions on the same acquisition channel. If all of them have the same bin register, which bins correspond to the first acquisition? The first bin (in the first repetition cycle), and the nth bin in the second repetition cycle, where n is the number of acquisitions on the same acquisition channel after the first. This n is very complicated to calculate: some operations might even be in a loop, some not, etc... The simple solution is to give a dedicated register for all append operations within the same acquisition channel.
• Previously the "acquisition metadata" was a dictionary, each key is the "acquisition channel" (bear in mind each "acquisition channel" corresponds to one unique "protocol" by definition), and that data was also bound to one unique sequencer. In practice, with our hardware it is possible to create schedules on the same sequencer, but with different kind of acquisition ("protocols"), but the way Quantify used "acquisition metadata" made this impossible. Now this is fixed; but still, we need to be careful, because some acquisition protocols clash with other protocols on the same sequencer still; for these, new checks have been added in the compiler (compiler_abc.py, analog.py, timetag.py).

---

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 for breaking changes and AUTHORS.md have been updated (or N/A).
• Update Hardware backends documentation if backend interface change or N/A
• Check whether performance is significantly affected by looking at the Performance metrics results.
• 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.