Add minimal support for standalone Var to visualisers

[jakelishman]

Summary

This adds best-effort only support to the visualisers for handling stand-alone Var nodes. Most of the changes are actually in qasm3, since the visualisers use internal details of that to handle the nodes.

This commit decouples the visualisers slightly more from the inner workings of the OQ3 exporter by having them manage their own variable-naming contexts and using the encapsulated _ExprBuilder, rather than poking into random internals of the full circuit exporter. This is necessary to allow the OQ3 exporter to expand to support these variables itself, and also for the visualisers, since variables may now be introduced in inner scopes.

This commit does not attempt to solve many of the known problems around zero-operand "gates", of which Store is one, just leaving it un-drawn. Printing to OpenQASM 3 is possibly a better visualisation strategy for large dynamic circuits for the time being.

Details and comments

Close #10937 (enough, at least, not to crash - it's not perfect by any stretch).

@enavarro51: would you be able to / like to review the changes to the visualisers that I made?

[qiskit-bot]

One or more of the the following people are requested to review this:

• @enavarro51
• @Qiskit/terra-core

[coveralls]

Pull Request Test Coverage Report for Build 8915026681

Warning: This coverage report may be inaccurate.

This pull request's base commit is no longer the HEAD commit of its target branch. This means it includes changes from outside the original pull request, including, potentially, unrelated coverage changes.

• For more information on this, see Tracking coverage changes with pull request builds.
• To avoid this issue with future PRs, see these Recommended CI Configurations.
• For a quick fix, rebase this PR at GitHub. Your next report should be accurate.

Details

• 31 of 61 (50.82%) changed or added relevant lines in 5 files are covered.
• 413 unchanged lines in 20 files lost coverage.
• Overall coverage increased (+0.09%) to 89.539%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
qiskit/qasm3/ast.py	5	6	83.33%
qiskit/visualization/circuit/text.py	19	22	86.36%
qiskit/qasm3/printer.py	2	6	33.33%
qiskit/qasm3/exporter.py	2	8	25.0%
qiskit/visualization/circuit/matplotlib.py	3	19	15.79%

Files with Coverage Reduction	New Missed Lines	%
qiskit/converters/circuit_to_gate.py	1	97.44%
qiskit/visualization/circuit/matplotlib.py	1	49.33%
qiskit/circuit/controlflow/control_flow.py	1	92.86%
qiskit/converters/circuit_to_instruction.py	1	98.28%
qiskit/circuit/library/blueprintcircuit.py	3	95.16%
qiskit/circuit/library/generalized_gates/isometry.py	3	94.59%
qiskit/providers/basic_provider/basic_provider_tools.py	5	86.49%
qiskit/circuit/_classical_resource_map.py	6	90.67%
crates/qasm2/src/lex.rs	6	92.62%
crates/qasm2/src/parse.rs	6	97.61%

Totals
Change from base Build 8882717215:	0.09%
Covered Lines:	61599
Relevant Lines:	68796

---

💛 - Coveralls

[mtreinish]

Besides a couple of typos this looks fine to me. I'm not a huge fan how coupled the visualizations and the oq3 exported code is though. It sort of reminds me of a light version of the oq2 parser and dagcircuit integration. But that's outside the scope of this PR.

[jakelishman]

Yeah, the coupling in the expr renderers isn't ideal, but hopefully this PR decouples them rather more. There's still a single private-class access, but that's also a component that's deliberately encapsulated away from the rest of the OQ3 exporter.

The coupling was a bit of a compromise - we don't have the resources to maintain the drawers as much as we'd like, and expression unparsing/formatting/whatever is not entirely trivial when it comes to determining when brackets are necessary in nested expressions. The OQ3 exporter already has to do that, so in the choice between duplicating additional code into the visualisers that'd need to be maintained and having a not-entirely-ideal coupling between the two, we tried out the coupling.

[mtreinish]

I'm fine with this as is. Code wise this looks fine and it unblocks the other PRs on the stack for var support. The piece that I think is missing from the visualizers functionally is the input and store side. Looking at the output visualizations just showing the variables in the expressions is potentially confusing because you don't know where a or b come from or what the values or types are. But also at a certain point I don't think graphical visualization makes sense anymore and we'll likely just want to dump qasm or something instead to reason about the contents of a circuit in a "human" readable way. So this is not a regression in anyway and it's better than crashing or actively erroring with a var in an expression. We can follow up here with more improvements later.