Make cutting-for-depth compatible with SingleQPDGates in the workflow

[garrison]

Right now, the cut_gates function, which is used in the cutting-for-depth workflow (tutorial 2), returns a circuit with TwoQubitQPDGates. At a minimum, we should make it possible to work with SingleQubitQPDGates in a cutting-for-depth workflow (see the motivation, below). It might even make sense to have cut_gates return a circuit with SingleQubitQPDGates instead of TwoQubitQPDGates, but we'd have to consider whether there would be any down-side to this approach.

Background

The cutting-for-width workflow (tutorial 1) is already phrased in terms of circuits with SingleQubitQPDGates. In partition_problem, label suffixes are attached to each SingleQubitQPDGate so a later step of the workflow can determine matching pairs of SingleQubitQPDGates:

https://github.com/Qiskit-Extensions/circuit-knitting-toolbox/blob/98af06eba28222123d8bac79213fa586805bc8b9/circuit_knitting/cutting/cutting_decomposition.py#L212-L218

The label suffix is then used to identify instructions that are part of the same QPDBasis when generating the experiments:

https://github.com/Qiskit-Extensions/circuit-knitting-toolbox/blob/98af06eba28222123d8bac79213fa586805bc8b9/circuit_knitting/cutting/cutting_experiments.py#L195-L197

however, the cutting-for-depth workflow (i.e., where the circuit does not separable into multiple pieces) rejects SingleQubitQPDGates:

https://github.com/Qiskit-Extensions/circuit-knitting-toolbox/blob/98af06eba28222123d8bac79213fa586805bc8b9/circuit_knitting/cutting/cutting_experiments.py#L237-L239

Motivation

It is possible to pass SingleQubitQPDGates through the transpiler, as demonstrated in #303 (original test) and #573 (docs). However, it's much trickier to pass TwoQubitQPDGates through the transpiler, since one instead needs to modify the target to add all-to-all connectivity of TwoQubitQPDGates. I haven't actually tried this, but I'm not wild about it for some reason.

The immediate goal of solving this issue is to remove caveat mentioned at the top of the how-to guide introduced in #573 .

Stretch goal

As we are refactoring to make this possible, it might be nice to think about how we could design it such that someone could perform cutting-for-width and cutting-for-depth in the same, hybrid workflow. That is, some of the cuts separate the circuit into distinct partitions, but not others.