Additional analysis metrics

[Kyle J Strand]

Follow-on to #334. From Kalan (source):

The following metrics make sense for their respective targets:

Program via ControlFlowGraph

• width
• uses_dynamic_control_flow: walk the blocks and look at their terminators. if any conditional jumps, then true, else false
• when no dynamic control flow: then the BasicBlock metrics make sense, because they can be folded into a single value because the execution flow is known.

BasicBlock

• width
• swap_count
• gate_volume
• qubits_used -> I don't think this needs to be cached, that adds complexity and unclear value. Caching on Program was key because of how and when it was called; I'd expect this to be called exactly once in the lifetime of ProgramStats

ExecutionGraph wrapping BasicBlock

I might rename this to something more specific like QubitGraph

• depth
• fidelity_estimate

ScheduledBasicBlock

• duration -> end time of flattened pulse program (TBD in a different, hefty PR)

[Kalan]

output qubit index relabeling due to SWAP insertion

this one is only relevant within the scope of quilc (which performs rewriting) and doesn't make sense to implement on a program itself (which doesn't). I removed the comment about it.

[Kyle J Strand]

Never mind, #334 is sufficient.