✨ QIR support on mapped level

What's the problem this feature will solve?

It would be great to additionally offer circuits on the mapped level as QIR in addition to QASM. At that level, it should also be guaranteed that the respective circuit can be represented in QIR. The same might not be true for higher levels in MQT Bench.

One immediate advantage of adding this is the ability to test QIR-based frameworks and tools.

Describe the solution you'd like

The mqt-bench Python package as well as the CLI should be able to generate QIR code.
Possible tools for making this possible are

• https://github.com/qBraid/qbraid-qir developed by qBraid (enabling QASM3 -> QIR)
• https://github.com/microsoft/qiskit-qir developed by Microsoft (enabling Qiskit -> QIR)
• https://github.com/CQCL/pytket-qir (enabling TKET -> QIR)

Given how we will be exporting to OpenQASM 3 soon anyway, we might opt to simply rely on the qBraid solution to further translate the QASM file to QIR. Although I am slightly afraid that this process might not be fully lossless, I believe it should be fine at the mapped level.

We could think about extending this to

• the native-gates level (should be more or less easily possible)
• the target-independent level (might be possible for some of the programs, but probably not all. For example, multi-controlled Toffoli gates)

Start by inspecting the mqt-bench Python package and CLI entry points, then compare the QIR conversion options listed in the issue, especially qBraid's QASM3-to-QIR path. Done means mapped-level circuits can be generated as QIR through both interfaces and their representability is guaranteed.