Add optional prune_classical_qubits setting for circuit generation

[swernli]

This change adds a parameter to Q# and OpenQASM circuit generation called prune_classical_qubits that will generate a simplified circuit diagram where qubits that are unused or purely classical (never enter superposition) are removed. This can be handy for places where the program comes from generated logic that may use more qubits than strictly needed. This is purely for visualizing the simplified circuit and does not perform any kind of execution optimization.

So a program like this that has nine qubits but doesn't really use all of them:

will by default show the full circuit as it does today:

but with prune_classical_qubits = True will remove the purely classical q1, q2, q4, q5, and q8:

[DmitryVasilevsky]

I'm a bit uneasy about this feature as it is. The trimmed circuit is not equivalent to the original and it may be confusing. For example, I can create this circuit:

operation Foo() : Result {
    use qs = Qubit[2];
    X(qs[0]);
    CNOT(qs[0], qs[1]);
    H(qs[1]);
    Ry(Std.Math.PI() / 2.0, qs[1]);
    X(qs[0]);
    MResetZ(qs[1])
}

In this circuit the first qubit is trimmable, but the second is not. We can compare original and resulting circuits.
Original:

Trimmed:

For the original circuit the result is always Zero. But for the trimmed circuit the result is always One.
I would rather see CNOT replaced with X in the resulting diagram, but that would not be easy. I think the feature still has merits as it is, but then I don't like the name of the parameter 'trim'. It feels like the diagrams should be equivalent. I think we need a scarier name for this parameter.
@minestarks already mentioned a different name would be better, but it was only from the 'trimming' point. I think the fact that the circuit becomes not equivalent should also be reflected in the name.

[swernli]

... I would rather see CNOT replaced with X in the resulting diagram, but that would not be easy. I think the feature still has merits as it is, but then I don't like the name of the parameter 'trim'. It feels like the diagrams should be equivalent.

@DmitryVasilevsky, I believe the new logic handles this appopriately. Using your same sample code, the output now looks the way you were hoping, keeping the circuit equivalent:

I'll need more tests to ensure this across different inputs though!

[swernli]

@DmitryVasilevsky @minestarks This is now ready for review with the updated behavior based on your feedback. No rush to get this in soon though.