⚡ Better performance in Qiskit import

[burgholzer]

What's the problem this feature will solve?

Right now, the Qiskit import introduced in #371 incurs some unnecessary copies when translating operations from Qiskit to our internal representation.
This is because the code is organised so that it can simultaneously/recursively handle CompoundOperations and QuantumComputations. However, only the QuantumComputation class has convenience methods for directly constructing gates in-place right now.
As a consequence, the Qiskit import just always constructs an operation and then moves it to the QuantumComputation or CompoundOperaton (incurring a copy).

Describe the solution you'd like

It should be possible to avoid the copy and always construct the operations in-place (even if they are nested in a CompoundOperation).
Most likely, the solution is to replace the current call sites where a Compound operation is used by creating a QuantumComputation, then recursively calling the gate import on that circuit (using the convenience functions for adding gates in-place), and afterwards use the to_operation method to turn the circuit into a CompoundOperation that can then be added to the circuit.

An alternative solution involves also exposing convenience functions for adding gates in-place to the CompoundOperation class similar to the QuantumComputation. However, this creates quite some overhead in documentation and in terms of lines of code and is, therefore, not the preferred solution.