Acquisition - `InstrumentCoordinator.retrieve_acquisition` returns an `xarray.Dataset` (QAE-674, #362)

Explanation of changes

(Note, for review, I suggest you go through each commit, then the changes are easier to understand.)

• Returning an xarray.Dataset from the InstrumentCoordinator instead of the Dict[Tuple[int, int], list(float)] before. Note: ScheduleGettable returns the same kind of data as before, it hasn't changed.
• Removing acq_mapping, because previously implementation contained lots of redundant information and same logic was implemented in multiple places: if data was needed, acq_metadata is used. (Note, this implementation in the MR is even a better than !515 (merged).)
• Renamed the "acq_protocol", because they were error prone (there was one mistake still), and to prepare for the later refactoring of the code, so that each protocol class handles the protocol implementation instead of code all over quantify-scheduler. (See Open Closed SOLID Principle.)
• All the sequencer related data is under the "sequencer" key in the program, since currently it's cumbersome to work with this, if they are all on the same level as "acq_metadata"
• Small refactorings for _QRMAcquisitionManager, so that data flow is now much easier to understand. (Making redundant variables like scope acquisition sequencer/channel removal, removal of unused functions, making everything private which is supposed to be private.)
• Replace unwarranted isinstance when checking if a component is a QRM or not to data reset with a more pythonic check.

Motivation of changes

To not make huge changes at first, the xarray Dataset variable names are the acquisition channels, and it is two dimensional: one for the acquisition index, and the other for the repetition number. In the longer term solution, as part of the acquisition redesign epic, the coordinates and the variable names are expected to change.

#362

---

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.